Re: Container membership alternative approach ACTION-27

On 15/12/12 17:19, Arnaud Le Hors wrote:
> Hi Bart,
> If we want to model LDP after a filesystem I think we should consider
> the unix filesystem which provides for "hard links" that are constrained
> to one system and symbolic links that can cross boundaries.

Hard links are also restricted so that an additional link is only to a 
file, not a directory.  This stops cycles; it's a more restrictive 
condition than is necessary for that.

They require reference counting and they are not what I understand 
"containment" to be (= one owner) from previous discussions.  Deletion 
of containers with delete of sub-tree becomes quite interesting (doable, 
but needs spec'ing).

If we have container management, I suggest we do not allow additional 
hard links unless someone makes a strong case for it.

	Andy

(who hasn't seen how we do soft links but I'm guessing its POST to a 
container of a some specific RDF document as a container entry.  The 
link is strongly managed by the container.)

>
> Regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>
>
> Bart van Leeuwen <Bart_van_Leeuwen@netage.nl> wrote on 12/14/2012
> 05:54:29 AM:
>
>  > From: Bart van Leeuwen <Bart_van_Leeuwen@netage.nl>
>  > To: public-ldp-wg@w3.org,
>  > Date: 12/14/2012 05:55 AM
>  > Subject: Container membership alternative approach ACTION-27
>  >
>  > Hi,
>  >
>  > Since our meeting at TPAC I've been thinking about our discussion of
>  > ISSUE-25 [1]. It resulted in the end in ACTION-27 which is a rewrite
>  > of the spec to comply with the resolution of the issue.
>  > As Steve Speicher stated in his email [2] there are already some
>  > issues raised with a more detailed description of what seems to be
>  > missing in the spec.
>  >
>  > I've always liked the idea of a resource being member of multiple
>  > containers. So I've tried to go over all the emails and discussion
>  > summaries I could find and see where a possible solution might lie
>  > or come up with one.
>  > One approach that immediately popped up in my head was the way that
>  > the long forgotten OS/2 Workplace Shell used to place objects in
>  > multiple folders. Instead of creating short cuts, it created a thing
>  > called a shadow.
>  > The shadow of a object was exactly what its name tells you, a direct
>  > reference to the original, not a pointer. you modify the shadow, you
>  > modify the original object and vice versa, the only exception to
>  > this is a deletion operation. If you delete the object, all the
>  > shadows disappear with it, if you delete the shadow, it will just
>  > delete the shadow not the original object.
>  >
>  > This would work perfectly well for a LDPR since the direct reference
>  > is the URI, PUT and DELETE will work on the original LDPR.
>  > For creating and deleting a shadow LDPR in a LDPC I still have to
>  > figure out the mechanics in a REST way, but there are probably
>  > enough bright minds to help with that.
>  > A GET on the container could return a list of real resources and
>  > maybe shadow resources through a subclass of rdfs:member?
>  > I did not yet figure out how to use this method with the
>  > membershipSubject / membershipPredicate construction
>  > In the overal spec I miss is what is addressed in ISSUE-21 the
>  > reverse membership, and in this case shadow, predicates on a LDPR.
>  >
>  > I'm pretty sure I overlook something very obvious, but at least I've
>  > made a brain dump now ;)
>  >
>  >
>  > [1] http://www.w3.org/2012/ldp/track/issues/25
>  > [2] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Nov/0198.html
>  >
>  > Met Vriendelijke Groet / With Kind Regards
>  > Bart van Leeuwen
>  > @semanticfire
>  >
>  > ##############################################################
>  > # netage.nl
>  > # http://netage.nl <http://netage.nl/>
>  > # Enschedepad 76
>  > # 1324 GJ Almere
>  > # The Netherlands
>  > # tel. +31(0)36-5347479
>  > ##############################################################

Received on Saturday, 15 December 2012 17:39:49 UTC