Re: Comments on the LDP Spec: Creating new Resources

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.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
>
>
>