- From: Alexandre Bertails <alexandre@bertails.org>
- Date: Thu, 9 Oct 2014 16:16:03 -0400
- To: Andrei Sambra <andrei@w3.org>
- Cc: public-ldp-comments@w3.org
On Thu, Oct 9, 2014 at 4: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* The interaction is driven by the rel='type' Link header [1], not by the RDF content... This was resolved in [2]. Alexandre [1] http://www.w3.org/TR/ldp/#h5_ldpc-post-createrdf [2] http://www.w3.org/2012/ldp/track/issues/91 > > -- 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. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >
Received on Thursday, 9 October 2014 20:16:30 UTC