- From: Andrei Sambra <andrei@w3.org>
- Date: Thu, 09 Oct 2014 16:21:37 -0400
- To: Alexandre Bertails <alexandre@bertails.org>
- CC: public-ldp-comments@w3.org
- Message-ID: <5436EE51.7040801@w3.org>
On 10/09/2014 04:16 PM, Alexandre Bertails wrote: > 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]. Good point. I totally forgot about issue 91, seeing that it is almost 1 year old, though I don't think the primer or the test suite reflect its resolution -- missing Link header for LDPR POST requests. (sorry if I'm picky) -- Andrei > > 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:21:44 UTC