Re: Comments on the LDP Spec: Creating new Resources

But, does this resolve the fundamental issue you had with the test suite,
Miguel? Does this understanding align with what the test suite is enforcing
or do we still have a problem there?

On Thu, Oct 9, 2014 at 4: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
>
>
>
>


-- 
*Cody Burleson*
Enterprise Web Architect, Base22

Mobile: +1 (214) 537-8782
Skype: codyburleson
Email: cody@base22.com
Blog: codyburleson.com

*Please be advised that I check and respond to mail **on the following
Central Standard Time schedule:*
*9:00 am, 1:00 pm, and 4:00 pm*

*Check my free/busy time.
<http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>*