- From: Andrei Sambra <andrei@w3.org>
- Date: Thu, 09 Oct 2014 16:09:01 -0400
- To: public-ldp-comments@w3.org
- Message-ID: <5436EB5D.1080908@w3.org>
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. >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >
Received on Thursday, 9 October 2014 20:09:08 UTC