- From: David Wood <david@3roundstones.com>
- Date: Thu, 9 Oct 2014 16:51:27 -0400
- To: Miguel Aragón <miguel.aragon@base22.com>
- Cc: Andrei Sambra <andrei@w3.org>, public-ldp-comments@w3.org
- Message-Id: <AE9F75AA-5FA8-4A58-9EAF-7F37CC98A019@3roundstones.com>
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.
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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
Received on Thursday, 9 October 2014 20:51:52 UTC