1 Richard's LDP 101

This is an attempt to explain on a high level what LDP does; in particular the model behind its notion of “containers”. It's a result of dinner conversations at the LDP F2F2 meeting.

1.1 The two things that LDP does

LDP does two things.

First, it clarifies a number of things about how you can interact with Linked Data resources, in particular what happens when you apply the HTTP PUT and PATCH verbs to those resources. This is basically just common sense and not too exciting. I will not talk about it further. An HTTP resource that follows these LDP rules is called an "LDP resource" or LDPR.

Second, it provides a facility for managing what I call "value sets": sets of triples that all share the same subject and property, but have different objects. (There are also "inverse value sets", which are sets of triples that all share the same property and object, but different subjects.) LDP calls these things "containers"; more on this choice of terms below.

1.2 Value sets

This is a value set:

   :foo :p1 :x.
   :foo :p1 :y.
   :foo :p1 :z.

This is an inverse value set:

   :a :p2 :foo.
   :b :p2 :foo.
   :c :p2 :foo.

Value sets are named with an IRI, and can be interacted with in various ways using HTTP. Let's say this is the IRI for the first value set above:

   </foo/p1>

Doing a GET on that will return the three triples above, plus some metadata that I will talk about later. It MAY also contain extra triples as determined by the server, for example a short summary description of the values (:x, :y, :z).

Note that the IRI of the value set (</foo/p1>) is different from the shared subject (:foo). In fact, the subject could be any IRI, it doesn't need to have an RDF representation or doesn't even have to be an HTTP IRI or dereferenceable. However, quite often it will be an RDF-bearing resource; I will talk later about how its representation could look like.

Note further that there could be multiple value sets with :foo as the subject. Here's another one:

   # A representation of </foo/p3>
   :foo :p3 :m
   :foo :p3 :n

The objects in the value set may be any RDF term, including literals. If they are IRIs, then again they may or may not have RDF representations.

LDP calls these value sets "containers". This name doesn't really make sense. It comes from the fact that you can *use* value sets to implement the functionality of a REST-style container. But actually value sets can be used for lots of things that don't really fit the term "container".

1.3 Three things you can do with value sets

Now, besides just doing GET on them, value sets provide three extra features: (i) simple manipulation through HTTP; (ii) resource creation with naming, and (iii) pagination. I'll talk about each of those. A given value set may or may not support any of these, although not all combinations are possible.

First, the additional HTTP verbs.

PUT on a value set replaces the values in it, if the value set supports this.

PATCH on a value set modifies the values in it. PATCH is useful to add or remove individual values, especially if the value set is big.

The spec currently implies that you can also have arbitrary other triples in a value set representation, and they could be managed through PUT and PATCH. That's a bug, I think. If you need other triples, then they should have :foo as their subject, and you should PUT/PATCH them onto :foo, not through </foo/p1>.

DELETE on a value set removes all the triples in it, if the value set supports deletion. Some value sets have recursive delete semantics. Doing DELETE on the value set first DELETEs each resource in the set. A value set where DELETE is recursive is called a "composition container". A value set without recursive delete is called an "aggregation container". These terms come from OO modelling.

Second: On a value set that supports resource creation, you can POST a representation to it, and that creates a new resource with a server-assigned IRI, and adds a triple to the value set with that new IRI as the object.

Third: On a value set that supports pagination, a GET on the value set only responds with a limited number of the triples, and a link to the next "page" in the metadata. This allows the server to split large value sets into smaller parts. The value set URL like <foo/p3> is itself considered the first page of that sequence of pages.

There are a number of additional things that some people (and by that I mean Roger) might want to do with value sets. The spec doesn't support that at the moment. It could be done as extensions.

One issue with LDP as currently designed is that it doesn't really give you flexibility to use these three abilities independently.

1.4 Metadata triples in value sets

Let me talk about the metadata triples in a value set. They are typically:

   <foo/p1> a ldp:Container;
     ldp:membershipSubject :foo;
     ldp:membershipPredicate :p1.

If there's paging:

   <foo/p1> ldp:next <foo/p1?p=2>.

If it's a backward value set, instead of ldp:membershipPredicate, we would have ldp:membershipPredicateInverse.

The type might be ldp:AggregationContainer or ldp:CompositionContainer; this makes the behaviour of DELETE explicit.

1.5 The representation of the value set's membership resource

Let me now talk about the representation of the subject resource. If that resource has a RDF-bearing representation, then it MAY also include the metadata of any value set that it is a subject of.

It MAY also include some or all of the triples in the value set. If the value set is big and paged, then probably it will have at most the triples from the first page. It's also reasonable to not include any of the value set triples at all. At any rate, clients can discover the value sets through the included metadata.