W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

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

From: Henry Story <henry.story@bblfish.net>
Date: Thu, 24 Jan 2013 16:33:16 +0100
Message-Id: <B45AF0FC-339E-4633-BA06-111CD7583793@bblfish.net>
To: Alexandre Bertails <bertails@w3.org>, Arnaud Le Hors <lehors@us.ibm.com>, public-ldp-wg@w3.org

On 24 Jan 2013, at 16:01, Henry Story <henry.story@bblfish.net> 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?

One could make the append rule more subtle for what I have 
called ldp:Content objects that I have talked  about today:

 A POST of a graph containing the triple:

  <> a ldp:Container 

would create a new container resource. That seems 
quite plausible....


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

Social Web Architect
http://bblfish.net/



Received on Thursday, 24 January 2013 15:34:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC