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

On 24 Jan 2013, at 17:42, Alexandre Bertails <bertails@w3.org> wrote:

> 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?).


RFC5988 on WebLinking  may help 
http://tools.ietf.org/html/rfc5988#section-5.5

It states that the rel value can be an IRI.

It should be possible therefore to add to the header the following 

Link: <http://www.w3.org/ns/ldp#Container>; rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"

Which would say in effect

  <> a ldp:Container .

So what is the difference when <> a ldp:Container appears in the header,
and when it appears in the body? There are two cases:

1. If the header is sent by the server, then one expects the
header data to be statements by the server. Since the server
is responsible for what is or is not a ldp:Container that would 
make it a reasonable place to put that. ( It would also be a useful
place for the server state who is making the statement 
in the content )

2. I am not so clear what is happening when the client puts 
the content in the header like that, rather than in the body.
The client is making a statement about the content, but when
is that different from when the client is making the statement
in the content? Clearly it could have a pragmatic role here
of saving the server from having to look through all the 
content, to decide what to do. But it would be nice to have
some guiding logical principles for what the difference
of meaning is.




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

Social Web Architect
http://bblfish.net/