- From: Andrei Sambra <andrei@w3.org>
- Date: Thu, 09 Oct 2014 16:03:37 -0400
- To: public-ldp-comments@w3.org
- Message-ID: <5436EA19.705@w3.org>
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:03:44 UTC