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:59:05 +0100
Message-Id: <575DFE2F-F495-46B0-87B2-C99739E855D2@bblfish.net>
To: Roger Menday <roger.menday@uk.fujitsu.com>, public-ldp-wg@w3.org

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:

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:

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

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

Received on Thursday, 24 January 2013 15:59:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:36 UTC