Re: Comments on the LDP Spec: Creating new Resources

Great :) Add Stanford and Fedora4 to the fragile agreement.

Thanks!

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

> Yeah I was basically doing what you describe. I was only sharing with you
> guys why I think a Slug header should be use instead of a relative URI. So
> yeah, that works for me.
>
> Best Regards
>
>
> On Oct 9, 2014, at 4:48 PM, David Wood <david@3roundstones.com> wrote:
>
> Hi Robert,
>
> I think the language that is in the spec regarding the slug already says
> what you said.
>
> Miguel was, I think, encouraging of the slug and discouraging of the use
> of relative URIs. I think that it is his implementation’s decision what to
> do when he encounters relative URIs, since that is a server decision.
>
> Miquel, are you happy to accept relative URIs if you have complete freedom
> as stated on how your implementation creates the relevant base URI?  I
> presented one scenario, but you could use others.
>
> Regards,
> Dave
> --
> http://about.me/david_wood
>
>
>
> On Oct 9, 2014, at 17:41, Robert Sanderson <azaroth42@gmail.com> wrote:
>
> Can someone clarify the fragile agreement please? :)
>
> My understanding is:
> * The server MAY reject the request.
> * The server MAY use the slug and use the body that doesn't talk about the
> slug
> * The server MAY not use the slug and either generate something else or
> use what's in the body
> * The server MAY rewrite the URIs in the body to use the slug
>
> Basically ... there's no actual requirements for server behavior, and
> hence we all independently agree on our respective implementation
> strategies, job well done?
>
> Rob
>
>
> On Thu, Oct 9, 2014 at 2:27 PM, David Wood <david@3roundstones.com> wrote:
>
>> So let’s declare victory and go home before one of us breaks our fragile
>> agreement :)
>>
>> Regards,
>> Dave
>> --
>> http://about.me/david_wood
>>
>>
>>
>> On Oct 9, 2014, at 17:19, Miguel Aragón <miguel.aragon@base22.com> wrote:
>>
>> I’m sorry I think I didn’t make myself clear. What you are saying is
>> exactly what I wanted to say. We mint the URI of the newly created resource
>> based on the content of the request. So for interoperability we prefer that
>> a Slug is specified instead of a relative resource.
>>
>> Best Regards
>>
>> On Oct 9, 2014, at 4:13 PM, Nandana Mihindukulasooriya <
>> nmihindu@fi.upm.es> wrote:
>>
>> Hi,
>>
>> IHMO, as David said the server has the freedom of honouring the slug or
>> not and also deciding what is the URI it wants to mint for the newly
>> created resources. But it doesn't mean that it will be interoperable i.e.
>> one of your LDP clients can't assume that any other LDP server that you
>> will post the resources will mint the same URI because the RDF
>> representation that is posted has some hints.
>>
>> I think it is the same for some rules used by Callimachus such as "If
>> there is a base URI in the doc, then that becomes the base URI.". I think
>> the LDP spec doesn't specially say what do when the posted content has
>> an explicit base URI. It just says use the URI of the created as the base.
>>
>> So I think having such policy in your server is not a violation of LDP
>> but your LDP clients can't expect the same from the other servers. However,
>> I think it is better to use slug for that purpose as proposed by LDP which
>> would be an interoperable way to do it.
>>
>> Best Regards,
>> Nandana
>>
>> 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.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>
>>> >>>>
>>> >>
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305
>
>
>
>


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305