Re: Comments on the LDP Spec: Creating new Resources

Oh, please tell me why :)

On Oct 9, 2014, at 3:33 PM, Alexandre Bertails <alexandre@bertails.org> wrote:

> On Thu, Oct 9, 2014 at 4:32 PM, Miguel Aragón <miguel.aragon@base22.com> wrote:
>> In our server resources are basically named graphs that contain a resource that shares the same name as the graph and additional resources that extend that resource (think, # resources). So for us, if you send a document like: [[ <somethingElse> a ldp:RDFSource. ]] to the URI: http://example.org/container/ we take that as if you are trying to create:
>> 
>> graph <http://example.org/container/somethingElse> {
>>        <http://example.org/container/somethingElse> a ldp:RDFSource.
>> }
>> 
>> That’s the way our platform works (not the way I think).
> 
> Ah, then I am afraid that this is just not LDP...
> 
> Alexandre
> 
>> 
>> On Oct 9, 2014, at 3:27 PM, Alexandre Bertails <alexandre@bertails.org> wrote:
>> 
>>> On Thu, Oct 9, 2014 at 4:24 PM, Miguel Aragón <miguel.aragon@base22.com> wrote:
>>>> I’m sorry Alexandre, could you elaborate? I didn’t understand your response.
>>> 
>>> Sure, but let me ask you a question first. You seem to think that the
>>> presence of the triple [[ <somethingElse> a ldp:RDFSource. ]] in what
>>> you post should create the resource <somethingElse>, module relative
>>> URI resolution.
>>> 
>>> Is that what you think?
>>> 
>>> Alexandre
>>> 
>>>> 
>>>> On Oct 9, 2014, at 3:21 PM, Alexandre Bertails <alexandre@bertails.org> wrote:
>>>> 
>>>>> On Thu, Oct 9, 2014 at 4:18 PM, Miguel Aragón <miguel.aragon@base22.com> wrote:
>>>>>> Hi Dave,
>>>>>> 
>>>>>> I’m ok with that, I just don’t want the LDP Spec to force us to support null
>>>>>> URIs and relative URIs without a base.
>>>>>> 
>>>>>> If that’s the case then the LDP test suite needs to be modified because it
>>>>>> sends both null URIs and relative URIs without a base (which may not be
>>>>>> allowed by all servers).
>>>>> 
>>>>> Miguel, you just do not control what resource get created using RDF,
>>>>> nor you control its interaction model...
>>>>> 
>>>>> Alexandre
>>>>> 
>>>>>> 
>>>>>> On Oct 9, 2014, at 3:14 PM, David Wood <david@3roundstones.com> wrote:
>>>>>> 
>>>>>> On Oct 9, 2014, at 16:04, Miguel Aragón <miguel.aragon@base22.com> wrote:
>>>>>> 
>>>>>> The approach that I’m offering allows applications to be moved from one
>>>>>> service to another. The problems with relative URIs are these:
>>>>>> 
>>>>>> 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. The base of the document needs to be: (parent’s URI)
>>>>>> + (slug created)
>>>>>> If a non empty, relative URI was specified. The base of the document needs
>>>>>> to be: (parent’s URI) <- making sure that it ends in a “/"
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> Hi Miguel,
>>>>>> 
>>>>>> Thank you for clarifying your position.
>>>>>> 
>>>>>> I think the thing that you are missing here is that the server always has
>>>>>> the final say. It is up to the server to decide what to do with a Slug or
>>>>>> when a base URI is missing. It might reject the request, use what it has or
>>>>>> something else. This is in accordance with Web Architecture.
>>>>>> 
>>>>>> For example, this issue report records what we (Callimachus Project) decided
>>>>>> to do:
>>>>>> https://github.com/3-Round-Stones/callimachus/issues/163
>>>>>> 
>>>>>> Still, if LDP wants to specify this more tightly to assist interoperability,
>>>>>> it will need to be careful. Deciding quickly could break a lot of services
>>>>>> that are close to LDP compliance now.
>>>>>> 
>>>>>> Regards,
>>>>>> Dave
>>>>>> --
>>>>>> http://about.me/david_wood
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Oct 9, 2014, at 2:58 PM, David Wood <david@3roundstones.com> wrote:
>>>>>> 
>>>>>> On Oct 9, 2014, at 15:51, Miguel Aragón <miguel.aragon@base22.com> wrote:
>>>>>> 
>>>>>> You say you like them, but you haven’t addressed the problems that I
>>>>>> described. I’m not saying they should be prohibited, I’m saying it shouldn’t
>>>>>> be mandatory to support them.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Hi Miguel,
>>>>>> 
>>>>>> I honestly don’t see the problem you say you outlined and I did in fact give
>>>>>> you a use case since you said you don’t have one. Relative resolution of
>>>>>> URIs to the base allows portability in both data and applications built on
>>>>>> that data.
>>>>>> 
>>>>>> Why is it difficult to support the generation of a URI based on the
>>>>>> concatenation of a base URI and a relative URI? I am not trying to be
>>>>>> difficult, I just don’t understand why that is hard.
>>>>>> 
>>>>>> Regards,
>>>>>> Dave
>>>>>> --
>>>>>> http://about.me/david_wood
>>>>>> 
>>>>>> 
>>>>>> On Oct 9, 2014, at 2:43 PM, Andrei Sambra <andrei@w3.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 10/09/2014 03:42 PM, David Wood 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.
>>>>>> 
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> Relative URIs are incredibly useful.
>>>>>> 
>>>>>> -- Andrei
>>>>>> 
>>>>>> 
>>>>>> 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 URI: 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 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:
>>>>>> 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.
>>>>>> 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/<timestamp>
>>>>>> would create URIs like:
>>>>>> <http://example.org/generic-requests/1412868212000>
>>>>>> <http://example.org/generic-requests/1412868258000>
>>>>>> <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:
>>>>>> 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.
>>>>>> 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.
>>>>>> 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
>>>>>> Mobile: +52 (811) 798 9357
>>>>>> Skype: miguel.araco
>>>>>> Email: miguel.aragon@base22.com
>>>>>> CONFIDENTIALITY 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:35:06 UTC