Containers

Because the spec currently defines only one type of container it is constantly the subject of controversy. While some people argue for a simpler model, others argue for a more flexible model. Rather than keeping on trying to convince one another that one way is better than the other it would seem wiser to just accept that there are different use cases and a single container alone just can't possibly satisfy everyone.

This document therefore introduces three different types of container that may provide everyone with what they need/prefer.

1 SimpleContainer

A type of container which uses a predefined predicate to simply link to its members, say ldp:member.

This effectively allows to keep the simple case simple, the LDP Spec Example 3 becomes:

@base <http://example.org/container1/>
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<>
   a ldp:SimpleContainer;
   dcterms:title "A very simple container";
   ldp:member <member1>, <member2>, <member3>.

2 DirectContainer

This type of container adds the flexibility of choosing what the membership triples look like by supporting: ldp:resourceContainer, ldp:containsRelation, and ldp:containedByRelation.

This supports the LDP Spec Example 5 and the SKOS example which become:

@base <http://example.org/netWorth/nw1/>
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology/>.
<>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:asset 
      <assetContainer/a1>,
      <assetContainer/a2>;
   o:liability 
      <liabilityContainer/l1>,
      <liabilityContainer/l2>,
      <liabilityContainer/l3>.

<assetContainer/>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:containerResource <>;
   ldp:containsRelation o:asset.

<liabilityContainer/>
   a ldp:DirectContainer;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:containerResource <>;
   ldp:containsRelation o:liability.

And:

@base <http://example.org/skosldpc/>
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix skos: <http://www.w3.org/2004/02/skos/core#>.

<> a ldp:DirectContainer, skos:ConceptScheme;
	ldp:containerResource <>;
	ldp:containedByRelation skos:inScheme;
	skos:prefLabel "Subject Heading".

</entry1> a skos:Concept;
	skos:inScheme <>.

3 IndirectContainer

This is essentially what we have in the spec today. This type of container adds an indirection with the ability to list as member a resource that is different from the one that is POSTed using ldp:insertedContentRelation.

This supports the FOAF example which becomes the following:

@base <http://example.org/arnaud>
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/> .

<> a ldp:IndirectContainer;
  ldp:containerResource <#me>;
  ldp:containsRelation foaf:knows;
  ldp:insertedContentRelation foaf:primaryTopic ;
  ldp:memberResource <http://example.org/steves> ; 
  ldp:memberResource <http://example.org/timbl> ; 
  ldp:memberResource <http://example.org/michel> .

<#me> a foaf:Person;
  foaf:knows <http://example.org/steves#me>;
  foaf:knows <http://example.org/timbl#me>;
  foaf:knows <http://example.org/michel#me>.

ldp:memberResource is what's currently called ldp:created. It links the container to the information resource that is created when POSTing.

4 Remarks

The semantics of ldp:IndirectContainer is essentially the same as that of ldp:Container today.

The semantics of ldp:DirectContainer is the same as that of ldp:Container today with the following constaint:

<>  ldp:insertedContentRelation ldp:MemberSubject;

The semantics of ldp:SimpleContainer is the same as that of ldp:Container today with the following contraints:

<>  ldp:containerResource <>;
    ldp:containsRelation ldp:member;
    ldp:insertedContentRelation ldp:MemberSubject;

None of this therefore introduces any new semantics per se.

This essentially gives us back default values, without the need for them and thus avoiding the non-monotonicity issue. Specifying anything that contradicts the above stated constraints, for instance setting ldp:containsRelation to o:asset on a DirectContainer, is an error.

ldp:memberResource is only present where it is needed: IndirectContainer. It can therefore be made mandatory in keeping with the decision on ldp:created on 11/18.

This document doesn't define any class hierarchy specifying how these different types relate to one another and to ldp:Container, nor whether ldp:Container is still even needed at all. This needs to be figured out.

Before default values were removed the spec used rdfs:member as the default membership predicate rather than ldp:member. Which predicate is actually used for SimpleContainer needs to be figured out.