Re: Container membership alternative approach ACTION-27

On the other hand, no filesystem has ever had the expressivity of RDF to describe relationships between files. The LDP will allow you to talk about collections of resources, add the same resource to multiple collections, have nested collections, even have collections that are members of themselves - whatever floats your boat - all expressed as RDF structures.

However, this is orthogonal to containers which are really only there for the purposes of lifecycle management of resources. If you throw a box (a container) in the trash then everything in the box is trashed along with it. 

There's a case for reflecting the container structure as RDF, but in my opinion that should be read-only and firmly in the LDP namespace so as not to confuse it with conventional RDF for describing collections (aggregations).

Steve.


On 14 Dec 2012, at 13:54, Bart van Leeuwen <Bart_van_Leeuwen@netage.nl> wrote:

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