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

* Alexandre Bertails <bertails@w3.org> [2013-01-24 11:42-0500]
> 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?).

text/ldp-container+turtle
text/ldp-resource+turtle
and of course the bastard combo text/ldp-cresource+turtle

What I think is more challenging is the intereactions with these
unholy freaks of nature. Is it worth upping the LDP bar to describe
interactions with them (POSTs and PUTs being the most interesting)?

Thinking of LDP as a surface for some application state, prescribing
interactions with a bug and its list of attachments through a common
interface doesn't seem hard. You look at the contents or the media
type and either manipulate the application store for the bug or fiddle
with its list of attachements. I think this only gets weird when you
feel you should be able to apply a general solution backed by a triple
store.

Are there compelling use cases for creating nested containers where
the nested container is *only* a container? I can't think of any off
the top of my head.


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

-- 
-ericP

Received on Thursday, 24 January 2013 18:31:25 UTC