Re: Comments on the LDP Spec: Creating new Resources

Hi Andrei,

I'm fine with that being the expected behavior, but I'd just like us to
agree that /is/ the expected behavior :)

Rob

On Thu, Oct 9, 2014 at 1:03 PM, Andrei Sambra <andrei@w3.org> wrote:

>
>
> On 10/09/2014 03:59 PM, Robert Sanderson wrote:
> > 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>
>
> This is perfectly fine, since in RDF you can have a document that
> contains one or more graphs that are not necessarily describing the
> document itself.
>
> So then the server would create a resource using the value of the Slug
> header and write the contents of the body to that resource.
>
> -- Andrei
>
> > 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