- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Sat, 15 Dec 2012 09:19:47 -0800
- To: Bart van Leeuwen <Bart_van_Leeuwen@netage.nl>
- Cc: public-ldp-wg@w3.org
- Message-ID: <OFB639CAE6.4D5812AF-ON88257AD5.0051C599-88257AD5.005F328F@us.ibm.com>
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. 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 > # Enschedepad 76 > # 1324 GJ Almere > # The Netherlands > # tel. +31(0)36-5347479 > ##############################################################
Received on Saturday, 15 December 2012 17:20:21 UTC