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

On 24 Jan 2013, at 16:37, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

> 
> On 24 Jan 2013, at 15:33, Henry Story wrote:
> 
>> 
>> 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
> 
> I didn't see ldp:Content before ? where's the reference ? 

I wrote it up here:
http://www.w3.org/2012/ldp/wiki/ISSUE-37#Create_ldp:Content_class

[[
It was argued [http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0274.html on 24 January 2013] that 
the name Resource is usually understood to cover very general things. It would be better to have a 
subClass for Content, like this:

<pre>
{
ldp:Content rdfs:subClassOf ldp:Resource;
    owl:disjointWith ldp:Container .

 ldp:contains rdfs:subPropertyOf rdfs:member ;
       rdfs:domain ldp:Container .
} defendedBy [ foaf:member <http://bblfish.net/people/henry/card#me ];
  = :proposal4
</pre>

One could then argue that a POST of a graph on a resource c that is an
ldp:Content can append those triples to the resource, as argued by 
[http://www.w3.org/2012/ldp/track/issues/45 Issue-45].
]]

So now the argument would be what type of twist does one add to that
when one POSTS 

  <> a ldp:Container 

to such an ldp:Content. Clearly: since we argued that a resource
can't be both, it follows that the server must create a new resource.


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

Social Web Architect
http://bblfish.net/