Re: recursive deletion (Re: Model questions)

* Bart van Leeuwen <Bart_van_Leeuwen@netage.nl> [2013-01-29 15:01+0100]
> "Wilde, Erik" <Erik.Wilde@emc.com> wrote on 29-01-2013 14:49:35:
> 
> > From: "Wilde, Erik" <Erik.Wilde@emc.com>
> > To: "Eric Prud'hommeaux" <eric@w3.org>, Roger Menday 
> > <roger.menday@uk.fujitsu.com>, 
> > Cc: "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
> > Date: 29-01-2013 14:50
> > Subject: Re: recursive deletion (Re: Model questions)
> > 
> > hello eric.
> > 
> > On 2013-01-29 14:04 , "Eric Prud'hommeaux" <eric@w3.org> wrote:
> > >It's hard to imagine that hackers checking out LDP will see much value 
> if
> > >it doesn't permit them to create and delete collections, leaving no crap
> > >for them to clean up. On the other hand, it's realy really hard to
> > >imagine deployment of recursive-delete in large systems unless they
> > >impose the rule "don't delete containers".
> > 
> > why not simply make it work like the web works? if you want your content
> > to be under the management of the LDP server, you embed the content, and
> > when the collection gets deleted, everything with it gets deleted, too. if
> > you want your content to be separate resources you manage yourself
> > (anywhere on the web), you create them (anywhere), and then the content
> > gets linked from the LDP entry. when you trash the collection, the links
> > disappear, but the content remains unaffected. what's the downside of such
> > a simple and clear model that simply leverages the difference between
> > embedding and linking?
> 
> +1 I like keeping a simple approach to the issue.
> 
> I wrote a email a bit earlier [1] where I mentioned the way some old 
> desktop system did it, with object residing in a container and objects 
> having a reflection in a container. The objects that reside in the 
> container, are deleted when the container gets deleted, deleting a 
> container with reflections just delete the reflection of the object but 
> the original stays untouched

Just to be certain I understand the proposal, which I interpret as a
moderate departure from the current LDP spec, a POST to a container
C would create no new resource (using the spec example):

    initialState: - empty container -
    action: POST C
        [] a o:Stock ; dcterms:title "IBM" ;
           o:value 100.00 ; dcterms:date "2012-01-01"^^xsd:date .
    finalState:
        page:1 {
            container: a bp:Container ;
                dcterms:title "The assets of JohnZSmith" ;
                bp:membershipSubject membership: ;
                bp:membershipPredicate o:asset .
            page:1 a bp:Page ;
                bp:pageOf container: ;
                bp:nextPage rdf:nil .
            membership: a o:NetWorth .
            membership: o:asset :a1 .
            :a1 a o:Stock ; dcterms:title "IBM" ; o:value 100.00 ;
                dcterms:title "IBM" ; dcterms:date "2012-01-01"^^xsd:date .
        }

(by the current spec, the local label :a1 would a separate URL, making
the last four lines:
            membership: o:asset asset:a1 .
            asset:a1 a o:Stock ; dcterms:title "IBM" ; o:value 100.00 .
        }
        asset:a1 { asset:a1 a o:Stock ; o:value 100.00 ;
                   dcterms:title "IBM" ; dcterms:date "2012-01-01"^^xsd:date }
)

I can see a bulk move of the data from what was the created resource
working for small resources, but accessing collections of large
resources would become impractical, forcing the paging size to 0.


> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Dec/0073.html
> 
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen
> @semanticfire
> 
> ##############################################################
> # netage.nl
> # http://netage.nl
> # Enschedepad 76
> # 1324 GJ Almere
> # The Netherlands
> # tel. +31(0)36-5347479
> ##############################################################

-- 
-ericP

Received on Tuesday, 29 January 2013 21:56:36 UTC