- From: Ashok Malhotra <ashok.malhotra@oracle.com>
- Date: Wed, 19 Dec 2012 05:43:34 -0800
- To: "Wilde, Erik" <Erik.Wilde@emc.com>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
See inline All the best, Ashok On 12/18/2012 10:10 PM, Wilde, Erik wrote: > hello ashok. > > On 2012-12-16 14:42 , "Ashok Malhotra"<ashok.malhotra@oracle.com> wrote: >> On 12/15/2012 5:37 PM, Wilde, Erik wrote: >>> how are members managed, how can they even be found, when the container >>> is gone? are we actually doing member management and containers are >>> optional? i'm a bit confused by the concept of container-less members. >>> cheers, dret. >> Members are identified by URIs. > yes, but how would you find those? REST wants us to build hypermedia APIs, > so if there is no navigable path to a URI (because a member is not a > member of any collection anymore), then these members effectively become > zombies, right? > >> I have two usecases in mind. First, I have existing resources that I >> want to >> import into a LDP system. For example, I have existing photographs or >> music tracks >> that I want to annotate and then put into a LDP container. > do you want to import them (a la media collection)? in this case, they get > a new URI and that will be managed in sync with the corresponding media > link entry. or do you want to just link to them from your metadata entry? > in that case, their URI is outside of the management domain of the LDP > server, and the LDP server just manages the metadata entries, but not the > blobs. I think the word "import" is misleading here. I just want to add resources in another store to a collection. All we need is a link that points to the resource in the other store. When the container is deleted the link is deleted as well. The resource is managed by the other store. > >> Second, and this is still controversial, if I want a LDPR to be able to >> belong to >> more than one container. > i can see that happening, but this is more secondary after we have figured > out how we approach the three different kinds of setups i described in my > last email about member management. > > thanks and cheers, > > dret. >
Received on Wednesday, 19 December 2012 13:44:05 UTC