Re: Container membership alternative approach ACTION-27

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