Hi Andy, I see a fundamental discussion here. As soon as you work with Linked Data (in any kind, not only containers) your point of view automatically gets "resource centred" while most triple stores are purely "triple centred": in a triple store, the existance of a resource depends on the existance of at least one triple, while in Linked Data it is in principle possible to have a resource with no triple at all (even though this is probably not a very interesting case - a bit like the empty set in maths, not really useful but constantly getting in the way ;-) ). And if you connect this with content management, this actually can make sense (e.g. a page in a semantic wiki does not need to have a triple initially).
In the LMF, we therefore had implemented a triple store with a separate notion of "resource". You could create and delete resources independently from triples. Since I wanted to be able to use different (more scalable, better tested) triple stores as backend, I am now trying to think of ways how to "weave" this resource concept into the existing APIs. But I admit it makes the data model a whole lot more complicated, especially if you also want to think about which container a resource belongs to, who "owns" a resource, etc. The LDP people apparently have found a way that tries to bridge the two concepts by introducing containers, where each resource has at least one triple relating it to the container it refers to. Personally, I am not a big fan of this approach, because it looks a bit like a "hack". I can also imagine that the strong containment notion comes from REST, it would fit the REST approach (with hierarchical URIs) very well. However, I agree with you that the strong containment is not a convincing solution. Somehow I also wonder how the LDP containers relates to the concept of named graphs as originally found in SPARQL but now also implemented in several of the triple stores (Sesame has it in the API directly). When working on Marmotta, I think that we do not need to strictly limit ourselves to the LDP recommendation. If we think that there are worthwhile extensions to the recommendation, we can offer them. If there are restrictions (like strong containment) that we think are inappropriate for many use cases, we can make them optional/configurable. In the end, the project is mostly about usable software ;-) I like your playlist example, btw. Another example would be groups/roles of a user. ;-) Greetings, Sebastian 2012/12/20 Andy Seaborne <[email protected]> > What do people think about LDP Containers? > > The LDP-WG has debating "containers" for ages and it is still going on. > At the face-to-face they decided on "strong containment" meaning if you > delete the container, then the resources in the container also gets > deleted. That is, there is management of resources. > > Links to un-managed things don't fit this model very well, if the links > are in the same LDP platform. > > (think of playlists with songs from your music library in them) > > Any insights here? > > Andy >
