Collection Types

Status: This is part of a proposed spec change being discussed Feb 2014.

LDP Collection Types

LDP defines two kinds of collections, Containers and Selections, which may be supported by LDP servers. Containers and Selections are LDP-RSs with server support for their added features but retaining all the properties of an LDP-RS.

An ldp:Container manages the lifecycle of a set of Web Resources through standard HTTP operations. The basic operations on a Containers are:

• Create a new Resource in the Container. Typically done with a POST to the URL of the Container, or a PUT at a new URL in a space managed by the container.

• Delete a Resource, removing it from the Container. Typically done with DELETE of the Resource URL.

• Discover which Resources are in the Container. Typically done with GET on the Container URL, returning Turtle data about the Container, including the URLs of all the contained Resources.

An ldp:Selection provides combined access a set of Resources. Selections may include non-information Resources, like people and events, if they are identified by Linked Data IRIs so that associated data is accessible. Each Selection is tailored to provide a particular view of its members, suitable for some range of applications. Other selections may provide different views of the same set of member Resources. The basic operations on an Selection are:

• Add a Resource to the Selection. Often this is done automatically by the server in response to specific events, such as other data sources changing. When it is done explicitly by a client, it is typically done with PATCH to add a Membership Triple.

• Remove a Resource from the Selection. As with adding, this may be done automatically by the server or explicitely via a PATCH to remove a Membership Triple.

• Download information about the Resources in the Selection. In general, this is done with a GET on the Selection URL which returns data including the IRIs of the members along with some triples related to those members. The related information is typically a subset of the triples that would be obtained by dereferencing the member IRIs. The related information may be segregated into named graphs in an RDF Dataset, allowing the client to see provenance.

More advanced operations on Selections which might be provided:

• Discovery of related Selections, including the results of various manipulations of Selections, such as filtering, sorting, and inlining different properties. In general, this is done with a GET on the Selection's rel=describedby URL.

• Creation of related Selections. When supported, this is generally done with a PATCH on the Selection's rel=describedby URL.

• Modify information about Resources in the Selection. In general, this is done with a PATCH on the Selection URL. This is a similar to PATCH-ing the individual member URLs, but may be significantly more efficient, as well as potentially providing atomicity, consistency, and isolation for the set of changes.

As with other LDPRs, collections make shared application data available to Web Clients, subject to various constraints. LDP defines client-server interactions over HTTP, but servers may offer other kinds of interactions as well, and may be providing an interface to data from backend systems rather that actually storing the data.

Several current and anticipated features of all LDP-RSs may be particularly useful for the collection types:

• Paging. Collections may be arbitrarily large, so it is important that servers can serve them as a sequence of subset pages, and that clients are still able to consume the data. Collections may even be unbounded, in which case there will be a rel=first but not a rel=last.

• While metadata can and should be included in the representation of the collection, because the overall state may be so large, the empty-collection triples should also be available via rel=describedby.

• Change notification (not yet standardized) on collections can be used to trigger actions related to the collected resources. For containers, this might include mirroring the new contained resources to load-sharing servers. For selections, notification allows selected properties of a large number of resources to be watched for changes at once, and application pre-cache structures to be efficiently maintained.

• With access control (not yet standardized), Selections might need to have delegated authority in order to access member state and might need to present different state triples to different clients, based on their levels of access.

LDP servers are require to maintain an enumeration of the LRPRs in a Container as part of the Container state in a form that makes Containers also be Selections. This means every Container is also a Selection of its contained Resources. This constraint does not follow from the definitions of Selection and Container, however, but is imposed in order to promote interoperability, so we do not formally consider ldp:Container a subclass of ldp:Selection. As a logical counterexample, consider that a client might have permission to POST to a container, and DELETE the resources it has posted, but not have permission to GET the container state. In this case, for this client, the Container acts as just a Container without also being a Selection.