Re: ISSUE-36: Summary of ways of making containers

On 01/24/2013 10:01 AM, Henry Story wrote:
>
> On 24 Jan 2013, at 15:24, Alexandre Bertails <bertails@w3.org> wrote:
>
>> On 01/23/2013 07:38 PM, Arnaud Le Hors wrote:
>>> If I got this right, the premise for doing anything else other than
>>> using POST the way it's done for other resources is that some don't want
>>> to pay the price of having to parse the content to find out what the
>>> type of the resource to be created is.
>>>
>>> Yet, it also seems to be accepted that in most cases one will parse the
>>> content to validate it anyway, if nothing else.
>>>
>>> Furthermore, it is also accepted that we can't depend on something like
>>> MKCOL and we need a fallback mechanism.
>>>
>>> Given all that, I have to ask: Why don't we just accept that finding out
>>> what type of resource needs to be created is a price some will have to
>>> pay and stick to POST?
>>
>> I'd be fine with that.
>
> Just a question: Is it only during the creation time
> when the POSTed content contains
>
>     <> a ldp:Container .
>
> that that action creates a Container?
>
> Or can one later append that triple to any resource to
> turn  it into a container?

I was expecting something like that to come up... And that's a
legitimate question. I would say that POSTing this triple to a
non-LDPC should not create a new container. But then, it brings other
questions, like, what does it mean when a client dereference the LDPR
and see this triple?

I don't see in the current spec anything that would help a client to
make a distinction between the true nature of the LDPC as it just
responds by saying it's an RDF document ("Content-Type: text/turtle"
in the example).

I have the feeling that we will need to pass some informations in the
headers if we don't want to create new content-type (another argument
in favor of the protocol specific meta?).

Alexandre.

>
>
>>
>> Alexandre.
>>
>>>
>>> In practice, I think there are two general categories of use cases. 1.
>>> generic/vanilla server that simply stores triples and regurgitates them
>>> without doing anything special with them. 2. application specific server
>>> - this is a bug tracking system for instance - which translates the
>>> triples into an actual application specific object.
>>>
>>> In the latter case, the server for sure will want to parse the content
>>> received to figure out exactly what type of object is to be created and
>>> if the content received has all the bits and pieces required to satisfy
>>> the application needs to create such an object. So, this requirement
>>> adds no extra burden.
>>>
>>> In the former case, there may be a real additional cost but is it
>>> significant enough to justify doing anything different? And there may be
>>> ways to optimize this by deferring that operation to when the server is
>>> required to actually do anything different.
>>> --
>>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>

Received on Thursday, 24 January 2013 16:42:15 UTC