Re: Comments on the LDP Spec: Creating new Resources

> I agree with both of you. In our case we would reject the request. That’s why I don’t want the server to restrict what the server does in this case.

I’m sorry, typo:  "That’s why I don’t want the Spec to restrict what the server does in this case."

On Oct 9, 2014, at 4:03 PM, Miguel Aragón <miguel.aragon@base22.com> wrote:

> I agree with both of you. In our case we would reject the request. That’s why I don’t want the server to restrict what the server does in this case.
> 
> On Oct 9, 2014, at 3:58 PM, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote:
> 
>> IHMO, as David said the server has the freedom of honouring the slug or not and also 
>> 
>> On Thu, Oct 9, 2014 at 10:55 PM, Miguel Aragón <miguel.aragon@base22.com> wrote:
>> That’s very weird, because our platform passed all the tests of the LDP testsuite (except some related to LDPNRs). I would suppose that if it isn’t an LDP it shouldn’t pass them, right?
>> From what I understand, LDP servers are in charge of what gets created on the platform, so deciding how the data is structured is something the server can do.
>> The pointers that you shared are about interaction models which I think its a very different topic, please share with me the pointer that you refer to again. I can’t see what is what we are not following.
>> 
>> And if you are not comfortable responding to my comments please don’t do it. I’m only trying to expose my opinion and the needs of our platform :).
>> 
>> Best regards,
>> Miguel
>> 
>> On Oct 9, 2014, at 3:39 PM, Alexandre Bertails <alexandre@bertails.org> wrote:
>> 
>> > On Thu, Oct 9, 2014 at 4:34 PM, Miguel Aragón <miguel.aragon@base22.com> wrote:
>> >> Oh, please tell me why :)
>> >
>> > Because that is not how the group decided how to do things?
>> >
>> > Pardon me if I sound condescendant, really, but what you are doing
>> > with your platform (driving the interaction with RDF) was discussed
>> > *many* times in this working group and what came out of this is
>> > fundamentally not what you are describing. The specification is very
>> > clear on that. See the pointer I gave earlier.
>> >
>> > What you are asking is something very different than what is achieved in LDP.
>> >
>> > Alexandre
>> >
>> >>
>> >> 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.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>
>> >>
>> 
>> 
>> 
>