Re: Comments on the LDP Spec: Creating new Resources

* David Wood <david@3roundstones.com> [2014-10-09 16:51-0400]
> On Oct 9, 2014, at 16:15, Miguel Aragón <miguel.aragon@base22.com> wrote:
> 
> > Sorry guys, I’m also not trying to be difficult, but that doesn’t work for us. We only allow one RDF resource with a independently resolvable URI inside of a document, and it’s named the same way as the graph. Our server is going to reject a request that specifies a Slug header and a non empty, relative URI.
> > 
> > And actually, what would you use as a base in that case?
> 
> 
> What we currently do is to:
>   - Assign a random identifier to add to the container URI. That becomes the default base URI.
>   - If there is a Slug, then add it to the container URI. That then becomes the base URI.
>   - If there is a base URI in the doc, then that becomes the base URI.
>   - Relative URIs in the document will resolve against the final computed base URI.

I think this is as good as it gets, but I admit that it's weird that
the URIs in that in-transit document are unknown until you've
identified the document as creating a particular resource. The screw
case is that your resource might depend on the contents of the
document, e.g. a container to which you can POST new cars and trucks
and create a resource like …/Car/7 or …/Truck/10. Here you essentially
have to parse the document twice; once with a spurious (or optimistic)
base, and once with the base that you finally end up creating.


> Regards,
> Dave
> --
> http://about.me/david_wood
> 
> 
> 
> > The URI of the resource that was created after the slug? So it would end up like this?
> > 
> > graph <http://…../objects/a> {
> > <<http://…../objects/b> a ldp:Container.
> > }
> > 
> > 
> > On Oct 9, 2014, at 3:09 PM, Andrei Sambra <andrei@w3.org> wrote:
> > 
> >> 
> >> On 10/09/2014 04:06 PM, Robert Sanderson wrote:
> >>> Hi Andrei,
> >>> 
> >>> I'm fine with that being the expected behavior, but I'd just like us to
> >>> agree that /is/ the expected behavior :)
> >> 
> >> Fair enough! :)
> >> 
> >> Maybe we can nudge one of the editors to make this clarification? (at
> >> least to the primer) *wink* *wink*
> >> 
> >> -- Andrei
> >> 
> >>> 
> >>> 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.
> >>>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>>> 
> >>>> 
> >>>> 
> >>> 
> >>> 
> >> 
> > 
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 10 October 2014 09:54:03 UTC