- From: Andrei Sambra <andrei@w3.org>
- Date: Thu, 09 Oct 2014 17:13:26 -0400
- To: public-ldp-comments@w3.org
- Message-ID: <5436FA76.2040009@w3.org>
I'm afraid this discussion is not leading anywhere. As Alexandre pointed
out, this issue was discussed at length and a resolution was produced [1].
What confused you (and me at some point) was that the resolution was not
properly reflected in the spec/primer and the test suite does not send a
Link header with POST requests to create LDPRs. I think that can be
fixed though.
Still, it doesn't change the fact that the interaction model is *not*
driven by the RDF sent by the client, but instead by the HTTP Link
headers. This makes a lot of sense, since creating new Web resources
should be done through the HTTP protocol and not based on the data being
sent over the wires -- i.e. you would not use GET to *post* a form that
creates a new resource.
-- Andrei
[1] http://www.w3.org/2012/ldp/track/issues/91
On 10/09/2014 05:04 PM, Miguel Aragón 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.
>
> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>>
>>
>
>
Received on Thursday, 9 October 2014 21:13:38 UTC