Re: Proposal for containers


On 30/01/13 16:23, Ashok Malhotra wrote:
> OK. Here goes

Good way to move forward :-)

Discussing the models with some colleagues and developers of Marmotta, 
we conclude than, like we do sometimes with REST, it is useful to use 
the metaphor of a filesystem to check it. In this case LDPC would be 
folders and LDPR files. Please, do not follow to a tee, it is just a 
attempt to simplify the things.

> Container Model
> A. Containers can contain containers
> Containers are LDPRs and should
> be added to contianers like any other LDPR.
> B. To add a container to a container, POST a (child) container
> representation to a (parent) container.
> C. Thus, a contianer can contain a mix of members and comtainers.
> (Some of the members may be links to LDPRs.)
> D. If you GET all members of a
> container that has nested components, you get all the contents,
> members and containers at the top level. That is, you do not get nested
> components.


We still have the issue how to create root container/s... Must any 
LDP-compliant server provide it?  Following the metaphor, the filesystem 
must needed to be created before adding folders or files to root.

> Composition and Aggregation
> E. If you delete a container you delete everything it contains.
> For nested containers this leads to a cascaded delete.
> F. If you do not want a member to be deleted when the container is deleted,
> do not include the member in the containers but rather include a link to
> the member in the container.

So LDPC follows the composition model, both for LDPRs and child LDPCs. I 
agree. In accordance with the metaphor, rdfs:member (or whatever 
ldp:membershipPredicate indicates) will be normal childs of containers, 
while links would be similar to (soft) symlinks in a filesystem.

Hope we'll start to converge...


Sergio Fernández
Salzburg Research
+43 662 2288 318
Jakob-Haringer Strasse 5/II
A-5020 Salzburg (Austria)

Received on Wednesday, 30 January 2013 17:26:46 UTC