- From: Miguel Aragón <miguel.aragon@base22.com>
- Date: Thu, 9 Oct 2014 15:15:15 -0500
- To: Andrei Sambra <andrei@w3.org>
- Cc: public-ldp-comments@w3.org
- Message-Id: <91EFAAB6-8E6D-4A80-921E-21AD6203B82F@base22.com>
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? 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:15:55 UTC