This document describes a set of best practices and simple approach for a read-write Linked Data architecture, based on HTTP access to web resources that describe their state using the RDF data model.

Linked Data Platform Resources

Introduction

Linked Data Platform Resources (LDPRs) are HTTP resources that conform to the simple patterns and conventions in this section. HTTP requests to access, modify, create or delete LDPRs are accepted and processed by LDP servers. Most LDPRs are domain-specific resources that contain data for an entity in some domain, which could be commercial, governmental, scientific, religious, or other.

Some of the rules defined in this document provide clarification and refinement of the base Linked Data rules [[LINKED-DATA]]; others address additional needs.

The rules for Linked Data Platform Resources address basic questions such as:

What resource representations should be used?
How is optimistic collision detection handled for updates?
What should client expectations be for changes to linked-to resources, such as type changes?
How can the server make it easy for the client to create resources?
How do I GET the representation of a large resource broken up into pages?

Additional non-normative guidance is available in the LDP Best Practices and Guidelines editor's draft that addresses questions such as:

What literal value types should be used?
Are there some typical vocabularies that should be reused?

The following sections define the conformance rules for LDP servers when serving LDPRs. Companion non-normative documents describe additional guidelines for use when interacting with LDPRs.

LDP-RS's representations may be too big, one strategy is to break up the response representation into client consumable chunks called pages. A separate LDP specification outlines the conformance rules around pagination [[LDP-PAGING]].

A LDP server can manage two kinds of LDPRs, those resources whose state is represented using RDF (LDP-RS) and those using other formats (LDP-NR). LDP-RSs have the unique quality that their representation is based on RDF, which addresses a number of use cases from web metadata, open data models, machine processable information, and automated processing by software agents [[!rdf11-concepts]]. LDP-NRs are almost anything on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RSs hold metadata associated with LDP-NRs in some cases.

Sample separation of Linked Data Platform Resource — Samples of different types of LDPRs

The LDP-NRs and LDP-RSs are simply sub-types of LDPRs, as illustrated in .

Resource

General

LDP servers MUST at least be HTTP/1.1 conformant servers [[!RFC7230]].

LDP servers MAY host a mixture of LDP-RSs and LDP-NRs. For example, it is common for LDP servers to need to host binary or text resources that do not have useful RDF representations.

LDP server responses MUST use entity tags (either weak or strong ones) as response `ETag` header values, for responses that contain resource representations or successful responses to HTTP `HEAD` requests.

LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP `Link` header with a target URI of `http://www.w3.org/ns/ldp#Resource`, and a link relation type of `type` (that is, `rel='type'`) in all responses to requests made to an LDPR's HTTP `Request-URI` [[!RFC5988]].

Note: The HTTP Link header is the method by which servers assert their support for the LDP specification on a specific resource in a way that clients can inspect dynamically at run-time. This is not equivalent to the presence of a (subject-URI, rdf:type, ldp:Resource) triple in an LDP-RS. The presence of the header asserts that the server complies with the LDP specification's constraints on HTTP interactions with LDPRs, that is it asserts that the resource has Etags, supports OPTIONS, and so on, which is not true of all Web resources.

Note: A LDP server can host a mixture of LDP-RSs and LDP-NRs, and therefore there is no implication that LDP support advertised on one HTTP Request-URI means that other resources on the same server are also LDPRs. Each HTTP Request-URI needs to be individually inspected, in the absence of outside information.

LDP servers MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP `Request-URI` when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.

LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with `rel='describedby'` [[!RFC5988]] to all responses to requests which fail due to violation of those constraints. For example, a server that refuses resource creation requests via HTTP PUT, POST, or PATCH would return this `Link` header on its 4xx responses to such requests. The same `Link` header MAY be provided on other responses. LDP neither defines nor constrains the representation of the link's target resource. Natural language constraint documents are therefore permitted, although machine-readable ones facilitate better client interactions.

HTTP GET

LDP servers MUST support the HTTP `GET` Method for LDPRs.

LDP servers MUST support the HTTP response headers defined in .

HTTP POST

Per [[!RFC7231]], this HTTP method is optional and this specification does not require LDP servers to support it. When a LDP server supports this method, this specification imposes no new requirements for LDPRs.

Clients can create LDPRs via POST () to a LDPC, via PUT (), or any other methods allowed for HTTP resources. Any server-imposed constraints on LDPR creation or update must be advertised to clients.

HTTP PUT

Any server-imposed constraints on LDPR creation or update must be advertised to clients.

If a HTTP `PUT` is accepted on an existing resource, LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request. LDP servers MAY ignore server-managed properties such as `dcterms:modified` and `dcterms:creator` if they are not under client control. Any LDP servers that wish to support a more sophisticated merge of data provided by the client with existing state stored on the server for a resource MUST use HTTP `PATCH`, not HTTP `PUT`.

LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs.

If an otherwise valid HTTP `PUT` request is received that attempts to change properties the server does not allow clients to modify, LDP servers MUST fail the request by responding with a 4xx range status code (typically 409 Conflict). LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP.

Non-normative note: Clients might provide properties equivalent to those already in the resource's state, e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the server-managed properties are identical on the GET response and the subsequent PUT request. This is in contrast to other cases like write-once properties that the server does not allow clients to modify once set; write-once properties are under client control, they are not server-managed.

If an otherwise valid HTTP `PUT` request is received that contains properties the server chooses not to persist, e.g. unknown content, LDP servers MUST respond with an appropriate 4xx range status code [[!RFC7231]]. LDP servers SHOULD provide a corresponding response body containing information about which properties could not be persisted. The format of the 4xx response body is not constrained by LDP. LDP servers expose these application-specific constraints as described in .

LDP clients SHOULD use the HTTP `If-Match` header and HTTP `ETags` to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. LDP servers SHOULD require the HTTP `If-Match` header and HTTP `ETags` to detect collisions. LDP servers MUST respond with status code 412 (Condition Failed) if `ETag`s fail to match when there are no other errors with the request [[!RFC7232]]. LDP servers that require conditional requests MUST respond with status code 428 (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].

LDP servers MAY choose to allow the creation of new resources using HTTP `PUT`.

HTTP DELETE

Additional requirements on HTTP DELETE for LDPRs within containers can be found in .

HTTP HEAD

Note that certain LDP mechanisms rely on HTTP headers, and HTTP generally requires that HEAD responses include the same headers as GET responses. Thus, implementers should also carefully read sections and .

LDP servers MUST support the HTTP `HEAD` method.

HTTP PATCH

Per [[!RFC5789]], this HTTP method is optional and this specification does not require LDP servers to support it. When a LDP server supports this method, this specification imposes the following new requirements for LDPRs.

Any server-imposed constraints on LDPR creation or update must be advertised to clients.

LDP servers that support `PATCH` MUST include an `Accept-Patch` HTTP response header [[!RFC5789]] on HTTP `OPTIONS` requests, listing patch document media type(s) supported by the server.

HTTP OPTIONS

This specification imposes the following new requirements on HTTP OPTIONS for LDPRs beyond those in [[!RFC7231]]. Other sections of this specification, for example PATCH, Accept-Post, add other requirements on OPTIONS responses.

LDP servers MUST support the HTTP `OPTIONS` method.

LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP `OPTIONS` request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header `Allow`.

RDF Source

The following section contains normative clauses for Linked Data Platform RDF Source.

General

Each LDP RDF Source MUST also be a conforming LDP Resource as defined in , along with the restrictions in this section. LDP clients MAY infer the following triple: one whose subject is the LDP-RS, whose predicate is `rdf:type`, and whose object is `ldp:Resource`, but there is no requirement to materialize this triple in the LDP-RS representation.

LDP-RSs representations SHOULD have at least one `rdf:type` set explicitly. This makes the representations much more useful to client applications that don’t support inferencing.

The representation of a LDP-RS MAY have an `rdf:type` of `ldp:RDFSource` for Linked Data Platform RDF Source.

LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP `Request-URI` of the LDP-RS is typically the subject of most triples in the response.

LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules.

LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever possible.

In the absence of special knowledge of the application or domain, LDP clients MUST assume that any LDP-RS can have multiple `rdf:type` triples with different objects.

In the absence of special knowledge of the application or domain, LDP clients MUST assume that the `rdf:type` values of a given LDP-RS can change over time.

LDP clients SHOULD always assume that the set of predicates for a LDP-RS of a particular type at an arbitrary server is open, in the sense that different resources of the same type may not all have the same set of predicates in their triples, and the set of predicates that are used in the state of any one LDP-RS is not limited to any pre-defined set.

LDP servers MUST NOT require LDP clients to implement inferencing in order to recognize the subset of content defined by LDP. Other specifications built on top of LDP may require clients to implement inferencing [[!rdf11-concepts]]. The practical implication is that all content defined by LDP must be explicitly represented, unless noted otherwise within this document.

A LDP client MUST preserve all triples retrieved from a LDP-RS using HTTP `GET` that it doesn’t change whether it understands the predicates or not, when its intent is to perform an update using HTTP `PUT`. The use of HTTP `PATCH` instead of HTTP `PUT` for update avoids this burden for clients [[!RFC5789]].

LDP clients MAY provide LDP-defined hints that allow servers to optimize the content of responses. defines hints that apply to LDP-RSs.

LDP clients MUST be capable of processing responses formed by a LDP server that ignores hints, including LDP-defined hints.

Feature At Risk

The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:

LDP clients SHOULD be capable of processing successful HTTP `GET` responses formed by a LDP server that independently initiated paging, returning a page of representation instead of full resource representation [[!LDP-PAGING]].

HTTP GET

LDP servers MUST provide a `text/turtle` representation of the requested LDP-RS whenever HTTP content negotiation does not force another outcome [[!turtle]]. In other words, if the server receives a `GET` request whose `Request-URI` identifies a LDP-RS, and either `text/turtle` has the highest relative quality factor (`q=` value) in the Accept request header or that header is absent, then an LDP server has to respond with Turtle.

LDP servers SHOULD offer a `application/ld+json` representation of the requested LDP-RS [[!JSON-LD]].

Non-RDF Source

The following section contains normative clauses for Linked Data Platform Non-RDF Source.

General

Each LDP Non-RDF Source MUST also be a conforming LDP Resource in . LDP Non-RDF Sources may not be able to fully express their state using RDF [[rdf11-concepts]].

LDP servers exposing an LDP Non-RDF Source MAY advertise this by exposing a HTTP `Link` header with a target URI of `http://www.w3.org/ns/ldp#NonRDFSource`, and a link relation type of `type` (that is, `rel='type'`) in responses to requests made to the LDP-NR's HTTP `Request-URI` [[!RFC5988]].

Linked Data Platform Containers

Introduction

Many HTTP applications and sites have organizing concepts that partition the overall space of resources into smaller containers. Blog posts are grouped into blogs, wiki pages are grouped into wikis, and products are grouped into catalogs. Each resource created in the application or site is created within an instance of one of these container-like entities, and users can list the existing artifacts within one. Containers answer some basic questions, which are:

To which URLs can I POST to create new resources?
Where can I GET a list of existing resources?
How do I get information about the members along with the container?
How can I ensure the resource data is easy to query?
How is the order of the container entries expressed? [[LDP-PAGING]]

This document defines the representation and behavior of containers that address these issues. There are multiple types of containers defined to support a variety of use cases, all that support a base set of capabilities. The contents of a container is defined by a set of triples in its representation (and state) called the containment triples that follow a fixed pattern. Additional types of containers allow for the set of members of a container to be defined by a set of triples in its representation called the membership triples that follow a consistent pattern (see the linked-to definition for the possible patterns). The membership triples of a container all have the same predicate, called the membership predicate, and either the subject or the object is also a consistent value – the remaining position of the membership triples (the one that varies) define the members of the container. In the simplest cases, the consistent value will be the LDPC resource's URI, but it does not have to be. The membership predicate is also variable and will often be a predicate from the server application vocabulary or the ldp:member predicate.

This document includes a set of guidelines for creating new resources and adding them to the list of resources linked to a container. It goes on to explain how to learn about a set of related resources, regardless of how they were created or added to the container's membership. It also defines behavior when resources created using a container are later deleted; deleting containers removes membership information and possibly performs some cleanup tasks on unreferenced member resources.

The following illustrates a very simple container with only three members and some information about the container (the fact that it is a container and a brief title):

Request to http://example.org/c1/:

GET /c1/ HTTP/1.1
Host: example.org
Accept: text/turtle

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "8caab0784220148bfe98b738d5bb6d13"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD,PUT
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/c1/>
   a ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains <r1>, <r2>, <r3>.

The preceding example is very straightforward: there are containment triples whose subject is the container, whose predicate is ldp:contains, and whose objects are the URIs of the contained resources, and there is no distinction between member resources and contained resources. A POST to this container will create a new resource and add it to the list of contained resources by adding a new containment triple to the container. This type of container is called a Linked Data Platform Basic Container.

Sometimes you have to build on existing models incrementally, so you have fewer degrees of freedom in the resource model. In these situations, it can be useful to help clients map LDP patterns onto existing vocabularies, or to include members not created via the container; LDP Direct Containers meet those kinds of needs. Direct Containers allow membership triples to use a subject other than the container itself as the consistent membership value, and/or to use a predicate from an application's domain model as the membership predicate. Let's start with a pre-existing domain resource for a person's net worth, as illustrated below:

Request to http://example.org/netWorth/nw1:

GET /netWorth/nw1 HTTP/1.1
Host: example.org
Accept: text/turtle

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:asset 
      <assets/a1>,
      <assets/a2>;
   o:liability 
      <liabilities/l1>,
      <liabilities/l2>,
      <liabilities/l3>.

In the preceding example, there is a rdf:type of o:NetWorth indicating the resource represents an instance of a person's net worth and a o:netWorthOf predicate indicating the associated person. There are two sets of same-subject, same-predicate triples; one for assets and one for liabilities. Existing domain-specific applications exist that depend on those types and predicates, so changing them incompatibly would be frowned upon.

It would be helpful to be able to use LDP patterns to manage the assets and liabilities-related triples. Doing so using a Basic Container would require duplicating much of the information with different types and predicates, which would be onerous for large resources. Direct Containers provide a middle ground, by giving LDP clients a way to map existing domain-specific resources to LDP's types and interaction models. In this specific example, it would be helpful to be able to manage the assets and liabilities triples consistently, for example by using LDP containers. One way to do this is to create two containers, one to manage assets and another liabilities, as separate HTTP resources. Existing clients have no need to interact with those containers, whereas LDP-enabled clients now have container URLs that they can interact with. The existing resource remains unchanged so that existing clients continue to function normally. This is illustrated in the set of related examples, one example per HTTP resource, starting with the LDP-RS example from before:

Request to http://example.org/netWorth/nw1:

GET /netWorth/nw1 HTTP/1.1
Host: example.org
Accept: text/turtle

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:asset 
      <assets/a1>,
      <assets/a2>;
   o:liability 
      <liabilities/l1>,
      <liabilities/l2>,
      <liabilities/l3>.

The structure of the net worth resource is completely unchanged, so any existing domain-specific applications continue to work without impact. LDP clients, on the other hand, have no way to understand that the asset and liability triples correspond in any way to LDP containers. For that, they need the next two resources.

The first container is a LDP Direct Container to manage assets. Direct Containers add the concept of membership and flexibility on how to specify the membership triples.

Request to http://example.org/netWorth/nw1/assets/:

GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "6df36eef2631a1795bfe9ab76760ea75"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Transfer-Encoding: chunked
      
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/assets/>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1>;
   ldp:hasMemberRelation o:asset;
   ldp:contains <a1>, <a2>.

In the preceding asset container, the consistent membership value (membership-constant-URI, still in the subject position) is not the container itself – it is the (separate) net worth resource. The membership predicate is o:asset, from the domain model. A POST of an asset representation to the asset container will create a new asset and add it to net-worth's list of assets by adding a new membership triple to the resource and a containment triple to the container.

The second container is a LDP Direct Container to manage liabilities.

Request to http://example.org/netWorth/nw1/liabilities/:

GET /netWorth/nw1/liabilities/ HTTP/1.1
Host: example.org
Accept: text/turtle

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "9f50da01f792281ddcfebe9788372d07"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/liabilities/>
   a ldp:DirectContainer;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1>;
   ldp:hasMemberRelation o:liability;
   ldp:contains <l1>, <l2>, <l3>.

The preceding liability container is completely analogous to the asset container above, simply managing liabilities instead of assets and using the o:liability predicate.

To add a another liability, a client would POST something like this to the liability container:

Request to http://example.org/netWorth/nw1/liabilities/:

POST /netWorth/nw1/liabilities/ HTTP/1.1
Host: example.org
Accept: text/turtle
Content-Type: text/turtle
Content-Length: 63

@prefix o: <http://example.org/ontology#>.

<>
   a o:Liability.
   # plus any other properties that the domain says liabilities have

Response:

HTTP/1.1 201 Created
Location: http://example.org/netWorth/nw1/liabilities/l4
Date: Thu, 12 Jun 2014 19:56:13 GMT
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"

Assuming the server successfully processes this request and assigns the URI <http://example.org/netWorth/nw1/liabilities/l4> to the newly created liability resource, at least two new triples would be added.

In the net worth resource, <http://example.org/netWorth/nw1> o:liability <liabilities/l4>
In the liability container, <http://example.org/netWorth/nw1/liabilities/> ldp:contains <l4>.

You might wonder why we chose to create two new containers instead of making http://example.org/netWorth/nw1 itself a container. A single net worth container would be a fine design if http://example.org/netWorth/nw1 had only assets or only liabilities (basically: only a single predicate to manage), but since it has separate predicates for assets and liabilities an ambiguity arises: it is unspecified whether a client's creation request (POST) should add a new o:asset or o:liability triple. Having separate http://example.org/netWorth/nw1/assets/ and http://example.org/netWorth/nw1/liabilities/ containers allows both assets and liabilities to be created and linked to the net-worth resource using the appropriate predicate. Similar ambiguities arise if the client wishes to list the members and/or contained resources.

Continuing in the multiple containers direction, we will now extend our net worth example to add a container for advisors (people) that have managed the assets and liabilities. We have decided to identify these advisors with URLs that contain a fragment (hash) to represent these real-world resources, not the documents that describe them.

Request to http://example.org/netWorth/nw1:

GET /netWorth/nw1 HTTP/1.1
Host: example.org
Accept: text/turtle

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "e8d129f45ca31848fb56213844a32b49"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked

@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:advisor
   	 <advisors/bob#me>,     # URI of a person
   	 <advisors/marsha#me>.
   	 
<advisors/>
   a ldp:IndirectContainer;
   dcterms:title "The asset advisors of JohnZSmith";
   ldp:membershipResource <>;
   ldp:hasMemberRelation o:advisor;
   ldp:insertedContentRelation foaf:primaryTopic;
   ldp:contains
   	 <bob>,     # URI of a document a.k.a. an information resource
   	 <marsha>.  # describing a person

To handle this type of indirection, the triple with predicate of ldp:insertedContentRelation and object of foaf:primaryTopic informs clients that when POSTing to this container, they need to include a triple of the form (<>, foaf:primaryTopic, topic-URI) to inform the server which URI to use (topic-URI) in the new membership triple.

This type of container is referred to as a LDP Indirect Container. It is similar to an LDP Direct Container but it provides an indirection to add (via a create request) as a member any resource, including a URI representing a real-world object. Create requests to LDP Direct Containers can only add information resources [[WEBARCH]] - the documents they create - as members.

To add a another advisor, a client would POST something like this to the advisors container:

Request to http://example.org/netWorth/nw1/advisors/:

POST /netWorth/nw1/advisors/ HTTP/1.1
Host: example.org
Accept: text/turtle
Content-Type: text/turtle
Slug: george
Content-Length: 72

@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix o: <http://example.org/ontology#>.
<>
   a o:Advisor;
   foaf:primaryTopic <#me>.
   # plus any other properties that the domain says advisors have

Response:

HTTP/1.1 201 Created
Location: http://example.org/netWorth/nw1/advisors/george
Date: Thu, 12 Jun 2014 19:56:13 GMT
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"

Assuming the server successfully processes this request and assigns the URI <http://example.org/netWorth/nw1/advisors/george> to the newly created advisor resource, at least two new triples would be added.

In the net worth resource, <http://example.org/netWorth/nw1> o:advisor <advisors/george#me>
In the advisors container, <http://example.org/netWorth/nw1/advisors/> ldp:contains <george>

In summary, illustrates the LDP-defined container types: Basic, Direct, and Indirect, along with their class relationship to types of LDPRs.

Types of Linked Data Platform Containers — Class relationship of types of Linked Data Platform Containers

The following table illustrates some differences between membership and containment triples. For details on the normative behavior, see appropriate sections below.

Completed Request	Effects
Completed Request	Membership	Containment
LDPR created in LDP-BC	New triple: (LDPC, ldp:contains, LDPR)	Same
LDPR created in LDP-DC	New triple links LDP-RS to created LDPR. LDP-RS URI may be same as LDP-DC	New triple: (LDPC, ldp:contains, LDPR)
LDPR created in LDP-IC	New triple links LDP-RS to content indicated URI	New triple: (LDPC, ldp:contains, LDPR)
LDPR is deleted	Membership triple may be removed	(LDPC, ldp:contains, LDPR) triple is removed
LDPC is deleted	Triples and member resources may be removed	Triples of form (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed

Retrieving Only Minimal-Container Triples

The representation of a container that has many members will be large. There are several important cases where clients need to access only the subset of the container's properties that are unrelated to member resources and unrelated to contained documents, for example to determine the membership triple pattern and membership predicate of an LDP-DC. LDP calls these minimal-container triples, because they are what remains when the container has zero members and zero contained resources. Since retrieving the whole container representation to get this information may be onerous for clients and cause unnecessary overhead on servers, we define a way to retrieve only these property values (and more generally, a way to retrieve only the subset of properties used to address other major clusters of use cases). LDP adds parameters to the HTTP Prefer header's return=representation preference for this (see for details).

The example listed here only shows a simple case where few minimal-container triples are retrieved. In real world situations more complex cases are likely, such as those that add other predicates to containers, for example providing validation information and associating SPARQL endpoints. [[sparql11-query]]

Here is an example requesting the minimal-container triples of a container identified by the URL http://example.org/container1/.

Request to http://example.org/container1/:

GET /container1/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.

<http://example.org/container1/>
   a ldp:DirectContainer;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipResource <http://example.org/container1/>;
   ldp:hasMemberRelation ldp:member;
   ldp:insertedContentRelation ldp:MemberSubject;
   dcterms:publisher <http://acme.com/>.

LDP recommends using PATCH to update these properties, if necessary. It provides no facility for updating them via PUT without replacing the entire container's state.

Container

The following section contains normative clauses for Linked Data Platform Container.

General

The Linked Data Platform does not define how clients discover LDPCs.

Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source. LDP clients MAY infer the following triple: one whose subject is the LDPC, whose predicate is `rdf:type`, and whose object is `ldp:RDFSource`, but there is no requirement to materialize this triple in the LDPC representation.

The representation of a LDPC MAY have an `rdf:type` of `ldp:Container` for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS.

LDPC representations SHOULD NOT use RDF container types `rdf:Bag`, `rdf:Seq` or `rdf:List`.

LDP servers exposing LDPCs MUST advertise their LDP support by exposing a HTTP `Link` header with a target URI matching the type of container (see below) the server supports, and a link relation type of `type` (that is, `rel='type'`) in all responses to requests made to the LDPC's HTTP `Request-URI`. LDP servers MAY provide additional HTTP `Link: rel='type'` headers. The notes on the corresponding LDPR constraint apply equally to LDPCs.

Valid container type URIs for rel='type' defined by this document are:

http://www.w3.org/ns/ldp#BasicContainer - for LDP Basic Containers
http://www.w3.org/ns/ldp#DirectContainer - for LDP Direct Containers
http://www.w3.org/ns/ldp#IndirectContainer - for LDP Indirect Containers

LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of a LDPC, particularly for large LDPCs. See also [[LDP-PAGING]].

HTTP GET

Per the HTTP GET method is required and additional requirements can be found in .

HTTP POST

Any server-imposed constraints on creation or update must be advertised to clients.

LDPC clients SHOULD create member resources by submitting a representation as the entity body of the HTTP `POST` to a known LDPC. If the resource was created successfully, LDP servers MUST respond with status code 201 (Created) and the `Location` header set to the new resource’s URL. Clients shall not expect any representation in the response entity body on a 201 (Created) response.

When a successful HTTP `POST` request to a LDPC results in the creation of a LDPR, a containment triple MUST be added to the state of the LDPC whose subject is the LDPC URI, whose predicate is `ldp:contains` and whose object is the URI for the newly created document (LDPR). Other triples may be added as well. The newly created LDPR appears as a contained resource of the LDPC until the newly created document is deleted or removed by other methods.

LDP servers MAY accept an HTTP `POST` of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources. See the Accept-Post section for details on how clients can discover whether a LDPC supports this behavior.

LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). If any requested interaction model cannot be honored, the server MUST fail the request.

If the request header specifies a LDPR interaction model, then the server MUST handle subsequent requests to the newly created resource's URI as if it is a LDPR. (even if the content contains an rdf:type triple indicating a type of LDPC).
If the request header specifies a LDPC interaction model, then the server MUST handle subsequent requests to the newly created resource's URI as if it is a LDPC.
This specification does not constrain the server's behavior in other cases.

Note: A consequence of this is that LDPCs can be used to create LDPCs, if the server supports doing so.

LDP servers MUST accept a request entity body with a request header of `Content-Type` with value of `text/turtle` [[!turtle]].

LDP servers SHOULD use the `Content-Type` request header to determine the representation format when the request has an entity body.

In RDF representations, LDP servers MUST interpret the null relative URI for the subject of triples in the LDPR representation in the request entity body as identifying the entity in the request body. Commonly, that entity is the model for the “to be created” LDPR, so triples whose subject is the null relative URI result in triples in the created resource whose subject is the created resource.

LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint.

LDP servers SHOULD allow clients to create new resources without requiring detailed knowledge of application-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers expose these application-specific constraints as described in .

LDP servers MAY allow clients to suggest the URI for a resource created through `POST`, using the HTTP `Slug` header as defined in [[!RFC5023]]. LDP adds no new requirements to this usage, so its presence functions as a client hint to the server providing a desired string to be incorporated into the server's final choice of resource URI.

LDP servers that allow member creation via `POST` SHOULD NOT re-use URIs.

Upon successful creation of an LDP-NR (HTTP status code of 201-Created and URI indicated by `Location` response header), LDP servers MAY create an associated LDP-RS to contain data about the newly created LDP-NR. If a LDP server creates this associated LDP-RS it MUST indicate its location on the HTTP response using the HTTP `Link` response header with link relation `describedby` and `href` to be the URI of the associated LDP-RS resource [[!RFC5988]].

LDP servers that support `POST` MUST include an `Accept-Post` response header on HTTP `OPTIONS` responses, listing `POST` request media type(s) supported by the server. LDP only specifies the use of `POST` for the purpose of creating new resources, but a server can accept `POST` requests with other semantics. While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when making requests to a LDP server, that every successful `POST` request will result in the creation of a new resource; they must rely on out of band information for knowledge of which `POST` requests, if any, will have the "create new resource" semantics. This requirement on LDP servers is intentionally stronger than the one levied in the header registration; it is unrealistic to expect all existing resources that support `POST` to suddenly return a new header or for all new specifications constraining `POST` to be aware of its existence and require it, but it is a reasonable requirement for new specifications such as LDP.

LDP servers SHOULD accept a request entity body with a request header of `Content-Type` with value of `application/ld+json` [[!JSON-LD]].

HTTP PUT

Any server-imposed constraints on creation or update must be advertised to clients.

LDP servers SHOULD NOT allow HTTP `PUT` to update a LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code.

LDP servers that allow LDPR creation via `PUT` SHOULD NOT re-use URIs.

HTTP DELETE

When a contained LDPR is deleted, the LDPC server MUST also remove the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC.

Non-normative note: The LDP server might perform additional actions, as described in the normative references like [[!RFC7231]]. For example, the server could remove membership triples referring to the deleted LDPR, perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time, and so on.

When a contained LDPR is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server MUST also delete the associated LDP-RS it created.

HTTP HEAD

Note that certain LDP mechanisms rely on HTTP headers, and HTTP recommends that HEAD responses include the same headers as GET responses. LDP servers must also include HTTP headers on responses to OPTIONS, see . Thus, implementers supporting HEAD should also carefully read the and .

HTTP PATCH

Any server-imposed constraints on LDPR creation or update must be advertised to clients.

LDP servers are RECOMMENDED to support HTTP `PATCH` as the preferred method for updating a LDPC's minimal-container triples.

HTTP OPTIONS

This specification imposes the following new requirements on HTTP OPTIONS for LDPCs. Note that support for this method is required for LDPCs, since it is required for LDPRs and LDPCs adhere to LDP-RS requirements.

When responding to requests whose `request-URI` is a LDP-NR with an associated LDP-RS, a LDPC server MUST provide the same HTTP `Link` response header as is required in the create response.

Basic

The following section contains normative clauses for Linked Data Platform Basic Container.

General

Each LDP Basic Container MUST also be a conforming LDP Container in along with the following restrictions in this section. LDP clients MAY infer the following triple: whose subject is the LDP Basic Container, whose predicate is `rdf:type`, and whose object is `ldp:Container`, but there is no requirement to materialize this triple in the LDP-BC representation.

Direct

The following section contains normative clauses for Linked Data Platform Direct Container.

General

Each LDP Direct Container MUST also be a conforming LDP Container in along the following restrictions. LDP clients MAY infer the following triple: whose subject is the LDP Direct Container, whose predicate is `rdf:type`, and whose object is `ldp:Container`, but there is no requirement to materialize this triple in the LDP-DC representation.

LDP Direct Containers SHOULD use the `ldp:member` predicate as a LDPC's membership predicate if there is no obvious predicate from an application vocabulary to use. The state of a LDPC includes information about which resources are its members, in the form of membership triples that follow a consistent pattern. The LDPC's state contains enough information for clients to discern the membership predicate, the other consistent membership value used in the container's membership triples (`membership-constant-URI`), and the position (subject or object) where those URIs occurs in the membership triples. Member resources can be any kind of resource identified by a URI, LDPR or otherwise.

Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the `ldp:membershipResource`, and whose object is the LDPC's `membership-constant-URI`. Commonly the LDPC's URI is the `membership-constant-URI`, but LDP does not require this.

Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, and whose predicate is either `ldp:hasMemberRelation` or `ldp:isMemberOfRelation`. The object of the triple is constrained by other sections, such as ldp:hasMemberRelation or ldp:isMemberOfRelation, based on the membership triple pattern used by the container.

LDP Direct Containers whose membership triple pattern is `( membership-constant-URI , membership-predicate , member-derived-URI )` MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is `ldp:hasMemberRelation`, and whose object is the URI of `membership-predicate`.

LDP Direct Containers whose membership triple pattern is `( member-derived-URI , membership-predicate , membership-constant-URI )` MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is `ldp:isMemberOfRelation`, and whose object is the URI of `membership-predicate`.

LDP Direct Containers MUST behave as if they have a `( LDPC URI, ldp:insertedContentRelation , ldp:MemberSubject )` triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation. The value `ldp:MemberSubject` means that the `member-derived-URI` is the URI assigned by the server to a document it creates; for example, if the client POSTs content to a container that causes the container to create a new LDPR, `ldp:MemberSubject` says that the `member-derived-URI` is the URI assigned to the newly created LDPR.

HTTP POST

When a successful HTTP `POST` request to a LDPC results in the creation of a LDPR, the LDPC MUST update its membership triples to reflect that addition, and the resulting membership triple MUST be consistent with any LDP-defined predicates it exposes. A LDP Direct Container's membership triples MAY also be modified via through other means.

HTTP DELETE

When a LDPR identified by the object of a membership triple which was originally created by the LDP-DC is deleted, the LDPC server MUST also remove the corresponding membership triple.

Indirect

The following section contains normative clauses for Linked Data Platform Indirect Container.

General

Each LDP Indirect Container MUST also be a conforming LDP Direct Container as described in , along with the following restrictions. LDP clients MAY infer the following triple: one whose subject is LDP Indirect Container, whose predicate is `rdf:type`, and whose object is `ldp:Container`, but there is no requirement to materialize this triple in the LDP-IC representation.

LDP Indirect Containers MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is `ldp:insertedContentRelation`, and whose object `ICR` describes how the `member-derived-URI` in the container's membership triples is chosen. The `member-derived-URI` is taken from some triple `( S, P, O )` in the document supplied by the client as input to the create request; if `ICR`'s value is `P`, then the `member-derived-URI` is `O`. LDP does not define the behavior when more than one triple containing the predicate `P` is present in the client's input. For example, if the client POSTs RDF content to a container that causes the container to create a new LDP-RS, and that content contains the triple `( <> , foaf:primaryTopic , bob#me )` `foaf:primaryTopic` says that the `member-derived-URI` is `bob#me`.

HTTP POST

LDPCs whose `ldp:insertedContentRelation` triple has an object other than `ldp:MemberSubject` and that create new resources MUST add a triple to the container whose subject is the container's URI, whose predicate is `ldp:contains`, and whose object is the newly created resource's URI (which will be different from the `member-derived URI` in this case). This `ldp:contains` triple can be the only link from the container to the newly created resource in certain cases.

HTTP Header Definitions

The Accept-Post Response Header

Feature At Risk

The LDP Working Group proposes incorporation of the features described in this section.

The addition of Accept-Post in this specification is pending advancement of an IETF draft [[Accept-Post]] that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]]. Once LDP is in Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF working with the W3C Director.

This specification introduces a new HTTP response header Accept-Post used to specify the document formats accepted by the server on HTTP POST requests. It is modelled after the Accept-Patch header defined in [[!RFC5789]].

The syntax for `Accept-Post`, using the ABNF syntax defined in Section 1.2 of [[!RFC7231]], is:

Accept-Post = "Accept-Post" ":" # media-range
The Accept-Post header specifies a comma-separated list of media ranges (with optional parameters) as defined by [[!RFC7231]], Section 5.3.2. The Accept-Post header, in effect, uses the same syntax as the HTTP Accept header minus the optional accept-params BNF production, since the latter does not apply to Accept-Post.

The `Accept-Post` HTTP header SHOULD appear in the `OPTIONS` response for any resource that supports the use of the `POST` method. The presence of the `Accept-Post` header in response to any method is an implicit indication that `POST` is allowed on the resource identified by the `Request-URI`. The presence of a specific document format in this header indicates that that specific format is allowed on `POST` requests to the resource identified by the `Request-URI`.

IANA Registration Template

The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).

Header field name: Accept-Post

Applicable Protocol: HTTP

Author/Change controller: W3C

Specification document: this specification

Preferences on the Prefer Request Header

Summary

This specification introduces new parameters on the HTTP Prefer request header's return=representation preference [[!RFC7240]], used optionally by clients to supply a hint to help the server form a response that is most appropriate to the client's needs. The LDP-defined parameters suggest the portion(s) of a resource's state that the client application is interested in and, if received, is likely to be processed. LDP Containers with large numbers of associated documents and/or members will have large representations, and many client applications may be interested in processing only a subset of the LDPC's information (for example, only membership triples or only containment triples), resulting in a potentially large savings in server, client, and network processing.

Non-normative note: LDP server implementers should carefully consider the effects of these preferences on caching, as described in section 2 of [[!RFC7240]].

Non-normative note: [[!RFC7240]] recommends that server implementers include a Preference-Applied response header when the client cannot otherwise determine the server's behavior with respect to honoring hints from the response content. Examples illustrates some cases where the header is unnecessary.

Specification

The `include` hint defines a subset of a LDPR's content that a client would like included in a representation. The syntax for the `include` parameter of the HTTP `Prefer` request header's `return=representation` preference [[!RFC7240]] is:

include-parameter = "include" *WSP "=" *WSP ldp-uri-list
Where WSP is whitespace [[!RFC5234]], and ldp-uri-list is a double-quoted blank-delimited unordered set of URIs whose ABNF is given below. The generic preference BNF [[!RFC7240]] allows either a quoted string or a token as the value of a preference parameter; LDP assigns a meaning to the value only when it is a quoted string of the form:
ldp-uri-list = DQUOTE *WSP URI *[ 1*WSP URI ] *WSP DQUOTE
where DQUOTE is a double quote [[!RFC5234]], and URI is an absolute URI with an optional fragment component [[!RFC3986]].

The `omit` hint defines a subset of a LDPR's content that a client would like omitted from a representation. The syntax for the `omit` parameter of the HTTP `Prefer` request header's `return=representation` preference [[!RFC7240]] is:

omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list
Where WSP and ldp-uri-list are defined as above for include.

When LDP servers receive a request with conflicting hints, this specification imposes no requirements on their behavior. They are free to reject the request, process it applying some subset of the hints, or anything else appropriate to the server. [[!RFC7240]] suggests treating similar requests as though none of the conflicting preferences were specified.

This specification defines the following URIs for clients to use with `include` and `omit` parameters. It assigns no meaning to other URIs, although other specifications MAY do so.

Containment triples	`http://www.w3.org/ns/ldp#PreferContainment`
Membership triples	`http://www.w3.org/ns/ldp#PreferMembership`
Minimal-container triples	`http://www.w3.org/ns/ldp#PreferMinimalContainer`
	or the equivalent but deprecated term
	`http://www.w3.org/ns/ldp#PreferEmptyContainer`

Non-normative note: all currently defined URIs are only coherent for LDP-RSs, and in fact only for LDPCs, however in the future it is possible that additional URIs with other scopes of applicability could be defined.

Examples

If we assume a container like the one below:

# The following is the representation of
#   http://example.org/netWorth/nw1/assets/

# @base <http://example.org/netWorth/nw1/assets/>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1>;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:asset <a1>, <a3>, <a2>.

<a1>
   a o:Stock;
   o:value 100.00 .
<a2>
   a o:Cash;
   o:value 50.00 .
<a3>
   a o:RealEstateHolding;
   o:value 300000 .

Clients interested only in information about the container (for example, which membership predicate it uses) might use this hint on a GET request: Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"

A server that honors this hint would return a following response containing the HTTP header Preference-Applied: return=representation and this representation:

Request to http://example.org/netWorth/nw1/assets/:

GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/assets/>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1>;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

Clients interested only in information about the container (same as before) might use this hint instead: Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment". Note: Treating the two as equivalent is not recommended. While today this omit parameter value is equivalent to the preceding include parameter value, they may not be equivalent in the future due to the definition of minimal-container triples. Clients should preferentially use the include parameter, as it more precisely communicates their needs.

A LDP 1.0 server that honors this hint would return the following response. Servers implementing later versions of LDP might return substantively different responses.

Request to http://example.org/netWorth/nw1/assets/:

GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation 
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/assets/>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1>;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

Clients interested only in information about the container (for example, which membership predicate it uses) and its membership might use this hint on a GET request: Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer".

A server that honors this hint would return (at least) the following response, and perhaps only this (it might well omit containment triples if they are not specifically requested). In cases like this example, where a client can detect from the content that its hints were honored (the presence of the predicates dcterms:title and o:asset demonstrate this in the representation below), there is no need for the server to include a Preference-Applied response header in many common cases like a 200 (OK) response. In other cases, like status code 303, the header would still be required for the client to know that the 303 response entity is a representation of the resource identified by the Location URI instead of a short hypertext note (one with a hyperlink to the same URI reference provided in the Location header field [[RFC7231]]).

Request to http://example.org/netWorth/nw1/assets/:

GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
      <http://www.w3.org/ns/ldp#Resource>; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology#>.

<http://example.org/netWorth/nw1/assets/>
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource <http://example.org/netWorth/nw1>;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:asset <a1>, <a3>, <a2>.

Change History

The change history is up to the editors to insert a brief summary of changes, ordered by most recent changes first and with heading from which public draft it has been changed from.

Summary

Summary of notable changes from the previous public working draft.

Resolved Last Call 2 comments
Removed references to RDF named graphs
Rename empty-container triples to minimal-container triples
Duplication (with intent to supersede) of the describedby relation type IANA registration, incorporating POWDER's relevant errata
Clarify definitions of membership and containment triples to avoid impression that they must be (stored as) part of the LDP-RS's state.
Servers should offer/accept JSON-LD representations of LDP-RSs
Updated all HTTP and Prefer-draft references to newly assigned RFC numbers, with associated BNF hits

Detailed history

2014-06-16 - Updated examples in Prefer section to be in request/response format (SS)
2014-06-16 - Updated examples in container sections to be in request/response format (SS)
2014-06-10 - Use http-bis and Prefer RFC numbers, adjust BNF to match bis changes (JA)
2014-06-05 - Fixed LC1 date in change history pseudo-heading, was 2014 (JA)
2014-05-19 - Revert membership definition to be about LDPCs, not LDP-RS's (JA)
2014-05-09 - Respond to Joe Ross's LC2 comments (JA)
2014-04-28 - Added usage for ldp:NonLDPSource (SS)
2014-04-28 - Clarify MUST etags on responses with representations and HEAD (SS)
2014-04-17 - Add should for json-ld per today's WG resolution (JA)
2014-04-16 - Update narrative on net worth example (#s 2-5, section 5.1, at time of writing) (JA)
2014-04-16 - Clarify language of 5.2.5.1/2 (JA)
2014-04-16 - Clarify definitions of membership and containment triples (JA)
2014-04-15 - Rename empty-container triples to minimal-container triples (JA)
2014-04-15 - Add describedby chapter (JA)
2014-04-15 - Removal of named graph references (JA)
2014-04-15 - Fixed typos (JA)
2014-04-15 - Fixed LC-2840 clarity on "burden of constraint" (SS)
2014-03-30 - Updated references to RFC5988 to first time Link header is used (SS)
2014-03-29 - Fixed error in Example 8 (SS)
2014-03-28 - Fixed copy-paste error in 5.4.1.1 (SS)
2014-03-28 - Set publication status and history for post 2nd LC edits (SS)

Last Call Draft (2014-03-11)

2014-03-03 - Must use LDPC subtypes for rel='type', per 20140303 resln (SS)
2014-03-03 - Removed LDP-BC clauses that introduce membership (SS)
2014-03-03 - Tweaked LDPR PUT clauses to better match new defn of LDPR (SS)
2014-03-03 - Folded #ldpclients section into #ldprs (SS)
2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)
2014-02-28 - Combined rules for container triples (SS)
2014-02-28 - Split out different kinds of LDPCs into their own subsection (SS)
2014-02-24 - Corrected rel=meta to be rel=describedby (SS)
2014-02-24 - Adjusted term membership triples and membership predicate (SS)
2014-02-24 - Removed 6.3.1 LDPC GET requirement and put in general clause (SS)
2014-02-20 - Changed LDPC SHOULD NOT put (6.5.1) to be about containment (SS)
2014-02-20 - Removed rule on PATCH create, as it doesn't add any substantive over RFC5789 (SS)
2014-02-18 - Factored out paging and sorting into separate spec LDP-Paging (SS)
2014-02-18 - Reference cleanup and tweak LDP-RS term (SS)
2014-02-17 - Reference to RDF Document into terms (SS)
2014-02-17 - Adopted container hierarchy and merged Indirect Container into Container (SS)
2014-02-17 - Adopted new resource types: LDP RDF Source (LDP-RS) (was LDP RDF Resource) and LDP Non-RDF Source (LDP-NR) (was LDP Binary Resource) (SS)
2014-02-17 - Adopted new predicate names: ldp:membershipResource, ldp:hasMemberRelation and ldp:isMemberOfRelation (SS)
2014-02-12 - Updated LDPR Post reference to Put, which had implied that clients could PUT (to an LDPC) to create an LDPR (JA)
2014-02-12 - Updated containerResource on examples 6 and 7, section 6.1, in resp to public-ldp email (JA)
2014-02-12 - Updated LDP-IC definition per email thread (JA)
2014-02-11 - Updated LDPC create ldp:contains (errant MAY to MUST, resolving conflicting statements) (JA)
2014-02-10 - Removed LDPR Paging HTTP OPTIONS section (no longer needed) and more cleanup of todos (SS)
2014-02-10 - Updated LDPC DELETE language and cleanup todos (SS)
2014-02-10 - Resolved a few editoral TODO's (JA)
2014-02-08 - Put final stake in heart of 'informative' (waves to Sandro), update boilerplate for readability per Arnaud (JA)
2014-02-08 - ACTION-132: Use Prefer in place of non-member properties resource (JA)
2014-02-08 - Add Prefer header examples, define new URIs from -126 in ttl, tweak acks per Arnaud email (JA)
2014-02-07 - ACTION-126: Add Prefer header (JA)
2014-02-07 - LDP-BCs use ldp:contains not ldp:member (JA)
2014-02-07 - Simplified some of the container examples (SS)
2014-02-06 - partial first pass at arnaud's email comments (JA)
2014-02-06 - fixing containment def, adding containment triples to terminology (JA)
2014-02-06 - fixing POST to create containment/membership triples, which was mangled (JA)
2014-02-06 - fully aligning SS changes with http://www.w3.org/2012/ldp/wiki/Containers for basic containers, allowing them to omit the standard predicates in representations despite requiring behavior consistent with the presence of those triples (JA)
2014-02-06 - editorial fixes (JA)
2014-02-06 - ACTION-127 (complete) use the TAG's new [23]xx code; if that code is not sufficiently through IETF process by CR, we will use a 303 (JA)
2014-02-05 - ACTION-133 Get rid of ldp:created which is subsumed by ldp:contains (SS)
2014-02-04 - ACTION-124 LDPR-RR as named graphs (SS)
2014-02-04 - ACTION-120 (complete) Updated LDPC general, GET and POST sections (SS)
2014-02-04 - ACTION-120 (Part 3) Added ldp:member (SS)
2014-02-04 - ACTION-120 (Part 2) Added concepts of containers (basic, direct and indirect) to LDPC intro (SS)
2014-01-30 - ACTION-120 (Part 1) Added concepts of containers (basic, direct and indirect) (SS)
2014-01-30 - ACTION-123 Added concepts of LDP-RDF-Resource and LDP-Binary-Resource (SS)
2014-01-29 - Fix up conformance section to use new LDP client section (SS)
2014-01-21 - Updated reference to LDP BP&G editor's draft and added ref to LDP-UCR (SS)
2014-01-21 - Removed redudant reqs that have been moved to #ldpclient (SS)
2014-01-21 - Fixed formating with >h2 formatting (SS)
2014-01-21 - Put reference to base-specs into intro section (SS)
2014-01-17 - First attempt at correcting section ordering and anchors (SS)
2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)
2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)
2013-11-27 - ACTION-101 Added informative security section (SS)
2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)
2013-11-18 - Various editorial and validation fixes (SS)
2013-11-12 - Clean up some remnants of inlining (JA)
2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)
2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)
2013-11-12 - Fix respec messages that only show up on remote server, hit paging examples to remove appearance of inlining (JA)
2013-11-11 - Resolve ACTION-113 Update spec to reflect 11/04 resolution to remove 303 and have client use first/next links to detect paging (JA)
2013-10-25 - Resolve ACTION-105 Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)
2013-10-25 - Resolve ACTION-110 Update spec to reflect 10/21 resolution for normative changes to align vanilla/chocolate (JA)
2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)
2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)
2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)
2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)
2013-10-22 - Resolve ACTION-108 move restatements of HTTP et al. out of normative sections (JA)
2013-10-22 - Resolve ACTION-106 5.3.5 MUST -> SHOULD (JA)
2013-10-21 - Mock up status code 209 Related Content (JA)
2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)
2013-10-01 - Revising terminology - membership triples and friends (JA)
2013-10-01 - Revising introduction (JA)
2013-10-01 - Conformance section drafting + mock up "LDP Clients" section as part of that (JA)
2013-09-23 - Remove client/server-initiated paging terms (JA)
2013-09-17 - Change must to MUST in 5.6.4 (SS)
2013-09-17 - Removed "at-risk" inlining feature from spec, ACTION-98 (SS)
2013-09-17 - Fixed vanishing section ref problem (SS)
2013-08-19 - Basic preparation for edits unto LC draft (SS)

Last Call Draft (2013-07-30)

2013-07-24 - Moved 4.7.2 (from HEAD) to 4.3.2 (GET), shifted rest of GET section by one (SS)
2013-07-24 - Moved 4.10.2.5->4.10.2.4.3,4.10.2.6->4.10.2.4.1,4.10.2.7->4.10.2.4.2 and added samples (SS)
2013-07-24 - Changed ldp:ascending->ldp:Ascending, ldp:descending->ldp:Descending, ldp:non-member-resource ->ldp:nonMemberResource (SS)
2013-07-24 - Added term "Page resource" (SS)
2013-07-24 - Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI (SS)
2013-07-23 - Added informative , therefore shifting all sections by one 4.1->4.2, etc (SS)
2013-07-23 - Changed to at risk as possibly moving to IETF (SS)
2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)
2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)
2013-07-17 - Various updates from suggests from Raúl (SS)
2013-07-15 - Inserted ldp:insertedContentRelation into examples (SS)
2013-07-15 - ISSUE-79 ldp:contains => ldp:created (JA)
2013-07-11 - Improving working in #ldpr-Paging to remove container references (SS)
2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13->6-11, 4.9.2.* fixup, 5.3.7-10->\2-5 (SS)
2013-07-11 - Removed all stubbed out sections 5.1.3, 5.3.2-6 (SS)
2013-07-11 - Various editorial clean up items from editor todo list (SS)
2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)
2013-07-11 - ISSUE-51 Added how an LDPR can show which LDPC is it in (SS)
2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)
2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)
2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)
2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:insertedContentRelation (SS)
2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive (JA)
2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)
2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)
2013-07-08 - ISSUE-79 ldp:contains (JA)
2013-07-08 - ISSUE-80 Accept-Post (JA)
2013-07-08 - ISSUE-32 Must support options (JA)
2013-07-08 - ISSUE-78 No client inferencing (JA)
2013-07-08 - ISSUE-77 Move "must have rdf:type explicitly" to Best Practices (JA)
2013-07-08 - ISSUE-57 Knowing it's an LDP server (JA)
2013-07-01 - ISSUE-33 Moved 5.1.3 Paging (LDPC) to 4.8 (LDPR) (SS)
2013-06-18 - ISSUE-75 5.2.5 membershipxxx predicates required, per 2013-06-18 F2F resolution (JA)
2013-06-18 - ISSUE-63 End of 5.3 + example rewritten for 2013-06-18 F2F resolution (JA)
2013-06-15 - ISSUE-14 End of 5.3 + example rewritten for ascending/descending sorts with optional collation (JA)
2013-06-13 - ISSUE-54 New 5.4.8.1 to set base URI on create for relative URI resolution (SS)
2013-06-10 - ISSUE-74 4.4.2 require 428 Condition Required status code when appropriate; SS adding 6585 to biblio (JA)
2013-06-05 - ISSUE-64 Remove ?non-member-properties; 5.1.2, 5.3.2, 5.5.2 (JA)
2013-05-21 - ISSUE-35 Re-use of URIs on create; 5.2.9, 5.4.11, 5.5.4 (JA)
2013-05-21 - ISSUE-43 Slug in LDPC POSTs; 5.4.8, 5.4.10 (JA)
2013-05-21 - ISSUE-65 Remove firstPage in favor of Link rel=first, mostly hits 5.3.3/5.3.4 (JA)
2013-05-17 - ISSUE-13 Updated 5.2.3 to say any resource can be in an LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)
2013-05-17 - Tweaks to Terminology section for LDPR and LDPC (SS)
2013-05-17 - ISSUE-9 Moved section 4.1.7 out of spec to the deployment guide (SS)
2013-05-15 - Updated wording for 5.2.2 from to be more clear (SS)
2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the deployment guide. (SS)
2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)
2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)
2013-04-15 - ISSUE-21 Added ldp:containedByRelation to 5.2.5 & 5.5.2, created 5.2.5.1 & 5.3.5.2 to indicate difference. (SS)
2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)
2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)
2013-04-08 - Fixed two old references to BPR (SS)
2013-03-17 - Inserted examples 2&3, a more complete NetWorth resource (SS)
2013-03-15 - Update LDPC glossary term based on Cody's feedback (SS)
2013-03-15 - Additional fix in 5.2.2 for ISSUE-34 (SS)
2013-03-15 - Remove reference to closed issues that don't require edits: ISSUE-27 & ISSUE-45 (SS)
2013-03-14 - General prep for 3rd draft, cleanup and a little restructure (SS)

Second Public Working Draft

2013-03-14 - Fixed up broken fragments and typos before publication (SS)
2013-03-04 - Comments received from David Wood: 5.3.7 & 5.1.3 clarity, other minor edits (part 2) (SS)
2013-03-04 - Comments received from David Wood: abstract, paging informative (part 1) (SS)
2013-03-04 - ISSUE-36 - Added informative text regarding creationg of containers in 5.4.4 (SS)
2013-03-04 - ISSUE-12 - Added section 4.7.3 not to allow PATCH for create (SS)
2013-03-03 - Adjustments to language about different container behavior (SS)
2013-03-02 - Adding trailing '/' on Container URLs to help with readability based on WG suggestion (SS)
2013-02-26 - Updated Acknowledgements section (SS)
2013-02-25 - ISSUE-29 - Use relative URIs in examples (SS)
2013-02-25 - ISSUE-31 - Added a more complete conformance section, motived by SPARQL 1.1 (SS)
2013-02-25 - Updating some simple formatting, reorganizing open issues and todos. (SS)
2013-02-15 - ISSUE-34 - Aggregration: 5.6.1 and 5.6.2 updated for review. (JA)
2013-02-13 - ISSUE-42 - 4.8 Common Properties moved to Deploment Guide (JA)
2013-02-12 - Fixed up previous publication links (SS)
2013-02-12 - ISSUE-10 - 4.1.12 to be MUST use entity tags (either weak or strong ones) (SS)
2013-02-12 - ISSUE-11 - 4.4.1 Relaxed the MUST ignore dc:modified/creator to MAY (SS)
2013-01-16 - ISSUE-25 Updated introduction. 5.2.2 changed to MUST NOT be in multiple containers. Flipped 5.6.1/2 as first rule leads to 2nd. 5.6.2(was .1) Delete LDPC MUST also delete members. (SS)
2013-01-16 - Added new issues ranging from 26-43. Removed closed/deferred issues: 2 & 3 (SS)
2012-12-28 - Fixed Typos. Separated some compound rules like 4.1.5. Rewording for clarity: 4.1.10, Text being repeated in several places centralized and cross-linked. Made printed code output easier to read on black & white printers. Exposed terms defined in-line under LDPC as Terminology (tentatively). Removed non-normative qualifer from section 5.2. Added "several" editors' to-dos.(JA)
2012-11-05 - minor rewording from ISSUE-24
2012-11-03 - ISSUE-22, ISSUE-23: changed sections 4.2.3 and 5.4.7. Removed closed issues. (SS)
2012-11-03 - ISSUE-24 Delete the phrase in 4.5.1 that nays "until ...Request URI" and adding a sentence, "Clients should note that servers may reuse a Request-URI under some circumstances."
2012-11-03 - ISSUE-6 Removed section 4.1.9. Shifted up sections .10 through .13.
2012-11-01 - Fixed minor typo and added some notes (SS)

First Public Working Draft

2012-10-15 - ISSUE-8 Changed references from LDBP to LDP, removed definition for "profile" and new namespace (SS)
2012-10-15 - Included additional open ISSUES from Oct 15 WG meeting: 22, 23, 24 (SS)
2012-10-14 - Added open ISSUES and formating to prep for public working draft (SS)
2012-09-20 - Sent pull request re LINKED-DATA and added suggestion for ldp namespace (SS)
2012-09-19 - Repairing references and forward reference to biblio.js updates (SS)
2012-09-19 - Fixed rdfs:label range to be rdfs:Literal (SS)
2012-09-19 - ISSUE-1 Define Turtle as the required serialization format for LDP (SS)
2012-09-18 - Initial ReSpec'ing of Member Submission - Linked Data Basic Profile 1.0 (SS)
2012-09-18 - Fixed up some links and worked on references, work left to do. (SS)

Submission

`membership-constant-URI`	`membership-predicate`	`member-derived-URI`
`member-derived-URI`	`membership-predicate`	`membership-constant-URI`

Introduction

Terminology

Conventions Used in This Document

Linked Data Platform Resources

Introduction

Resource

General

LDP servers MUST at least be HTTP/1.1 conformant servers [[!RFC7230]].

LDP servers MAY host a mixture of LDP-RSs and LDP-NRs. For example, it is common for LDP servers to need to host binary or text resources that do not have useful RDF representations.

LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values, for responses that contain resource representations or successful responses to HTTP HEAD requests.

LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#Resource, and a link relation type of type (that is, rel='type') in all responses to requests made to an LDPR's HTTP Request-URI [[!RFC5988]].

LDP servers MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.

HTTP GET

LDP servers MUST support the HTTP GET Method for LDPRs.

LDP servers MUST support the HTTP response headers defined in .

HTTP POST

HTTP PUT

LDP servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints. This is a consequence of the requirement to enable simple creation and modification of LDPRs.

LDP servers MAY choose to allow the creation of new resources using HTTP PUT.

HTTP DELETE

HTTP HEAD

LDP servers MUST support the HTTP HEAD method.

HTTP PATCH

LDP servers that support PATCH MUST include an Accept-Patch HTTP response header [[!RFC5789]] on HTTP OPTIONS requests, listing patch document media type(s) supported by the server.

HTTP OPTIONS

LDP servers MUST support the HTTP OPTIONS method.

LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.

RDF Source

General

LDP-RSs representations SHOULD have at least one rdf:type set explicitly. This makes the representations much more useful to client applications that don’t support inferencing.

The representation of a LDP-RS MAY have an rdf:type of ldp:RDFSource for Linked Data Platform RDF Source.

LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP Request-URI of the LDP-RS is typically the subject of most triples in the response.

LDP-RSs SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms. In addition to this general rule, some specific cases are covered by other conformance rules.

LDP-RSs predicates SHOULD use standard vocabularies such as Dublin Core [[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever possible.

In the absence of special knowledge of the application or domain, LDP clients MUST assume that any LDP-RS can have multiple rdf:type triples with different objects.

In the absence of special knowledge of the application or domain, LDP clients MUST assume that the rdf:type values of a given LDP-RS can change over time.

LDP clients MAY provide LDP-defined hints that allow servers to optimize the content of responses. defines hints that apply to LDP-RSs.

LDP clients MUST be capable of processing responses formed by a LDP server that ignores hints, including LDP-defined hints.

LDP clients SHOULD be capable of processing successful HTTP GET responses formed by a LDP server that independently initiated paging, returning a page of representation instead of full resource representation [[!LDP-PAGING]].

HTTP GET

LDP servers SHOULD offer a application/ld+json representation of the requested LDP-RS [[!JSON-LD]].

Non-RDF Source

General

Each LDP Non-RDF Source MUST also be a conforming LDP Resource in . LDP Non-RDF Sources may not be able to fully express their state using RDF [[rdf11-concepts]].

LDP servers exposing an LDP Non-RDF Source MAY advertise this by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp#NonRDFSource, and a link relation type of type (that is, rel='type') in responses to requests made to the LDP-NR's HTTP Request-URI [[!RFC5988]].

Linked Data Platform Containers

Introduction

Retrieving Only Minimal-Container Triples

Container

General

The representation of a LDPC MAY have an rdf:type of ldp:Container for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS.

LDPC representations SHOULD NOT use RDF container types rdf:Bag, rdf:Seq or rdf:List.

LDP servers SHOULD respect all of a client's LDP-defined hints, for example which subsets of LDP-defined state the client is interested in processing, to influence the set of triples returned in representations of a LDPC, particularly for large LDPCs. See also [[LDP-PAGING]].

HTTP GET

HTTP POST

LDP servers MAY accept an HTTP POST of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources. See the Accept-Post section for details on how clients can discover whether a LDPC supports this behavior.

LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s). If any requested interaction model cannot be honored, the server MUST fail the request.

LDP servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle [[!turtle]].

LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body.

LDP servers SHOULD assign the URI for the resource to be created using server application specific rules in the absence of a client hint.

LDP servers that allow member creation via POST SHOULD NOT re-use URIs.

LDP servers SHOULD accept a request entity body with a request header of Content-Type with value of application/ld+json [[!JSON-LD]].

HTTP PUT

LDP servers SHOULD NOT allow HTTP PUT to update a LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code.

LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs.

HTTP DELETE

When a contained LDPR is deleted, the LDPC server MUST also remove the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC.

When a contained LDPR is deleted, and the LDPC server created an associated LDP-RS (see the LDPC POST section), the LDPC server MUST also delete the associated LDP-RS it created.

HTTP HEAD

HTTP PATCH

LDP servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating a LDPC's minimal-container triples.

HTTP OPTIONS

When responding to requests whose request-URI is a LDP-NR with an associated LDP-RS, a LDPC server MUST provide the same HTTP Link response header as is required in the create response.

Basic

General

Direct

General

Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the ldp:membershipResource, and whose object is the LDPC's membership-constant-URI. Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this.

LDP Direct Containers whose membership triple pattern is ( membership-constant-URI , membership-predicate , member-derived-URI ) MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is ldp:hasMemberRelation, and whose object is the URI of membership-predicate.

LDP Direct Containers whose membership triple pattern is ( member-derived-URI , membership-predicate , membership-constant-URI ) MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is ldp:isMemberOfRelation, and whose object is the URI of membership-predicate.

LDP server responses MUST use entity tags (either weak or strong ones) as response `ETag` header values, for responses that contain resource representations or successful responses to HTTP `HEAD` requests.

LDP servers exposing LDPRs MUST advertise their LDP support by exposing a HTTP `Link` header with a target URI of `http://www.w3.org/ns/ldp#Resource`, and a link relation type of `type` (that is, `rel='type'`) in all responses to requests made to an LDPR's HTTP `Request-URI` [[!RFC5988]].

LDP servers MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP `Request-URI` when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.

LDP servers MUST support the HTTP `GET` Method for LDPRs.

LDP servers MAY choose to allow the creation of new resources using HTTP `PUT`.

LDP servers MUST support the HTTP `HEAD` method.

LDP servers that support `PATCH` MUST include an `Accept-Patch` HTTP response header [[!RFC5789]] on HTTP `OPTIONS` requests, listing patch document media type(s) supported by the server.

LDP servers MUST support the HTTP `OPTIONS` method.

LDP servers MUST indicate their support for HTTP Methods by responding to a HTTP `OPTIONS` request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header `Allow`.

LDP-RSs representations SHOULD have at least one `rdf:type` set explicitly. This makes the representations much more useful to client applications that don’t support inferencing.

The representation of a LDP-RS MAY have an `rdf:type` of `ldp:RDFSource` for Linked Data Platform RDF Source.

LDP servers MUST provide an RDF representation for LDP-RSs. The HTTP `Request-URI` of the LDP-RS is typically the subject of most triples in the response.

In the absence of special knowledge of the application or domain, LDP clients MUST assume that any LDP-RS can have multiple `rdf:type` triples with different objects.

In the absence of special knowledge of the application or domain, LDP clients MUST assume that the `rdf:type` values of a given LDP-RS can change over time.

LDP clients SHOULD be capable of processing successful HTTP `GET` responses formed by a LDP server that independently initiated paging, returning a page of representation instead of full resource representation [[!LDP-PAGING]].

LDP servers SHOULD offer a `application/ld+json` representation of the requested LDP-RS [[!JSON-LD]].

LDP servers exposing an LDP Non-RDF Source MAY advertise this by exposing a HTTP `Link` header with a target URI of `http://www.w3.org/ns/ldp#NonRDFSource`, and a link relation type of `type` (that is, `rel='type'`) in responses to requests made to the LDP-NR's HTTP `Request-URI` [[!RFC5988]].

The representation of a LDPC MAY have an `rdf:type` of `ldp:Container` for Linked Data Platform Container. Non-normative note: LDPCs might have additional types, like any LDP-RS.

LDPC representations SHOULD NOT use RDF container types `rdf:Bag`, `rdf:Seq` or `rdf:List`.

LDP servers MAY accept an HTTP `POST` of non-RDF representations (LDP-NRs) for creation of any kind of resource, for example binary resources. See the Accept-Post section for details on how clients can discover whether a LDPC supports this behavior.

LDP servers MUST accept a request entity body with a request header of `Content-Type` with value of `text/turtle` [[!turtle]].

LDP servers SHOULD use the `Content-Type` request header to determine the representation format when the request has an entity body.

LDP servers that allow member creation via `POST` SHOULD NOT re-use URIs.

LDP servers SHOULD accept a request entity body with a request header of `Content-Type` with value of `application/ld+json` [[!JSON-LD]].

LDP servers SHOULD NOT allow HTTP `PUT` to update a LDPC’s containment triples; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code.

LDP servers that allow LDPR creation via `PUT` SHOULD NOT re-use URIs.

LDP servers are RECOMMENDED to support HTTP `PATCH` as the preferred method for updating a LDPC's minimal-container triples.

When responding to requests whose `request-URI` is a LDP-NR with an associated LDP-RS, a LDPC server MUST provide the same HTTP `Link` response header as is required in the create response.

Each LDP Direct Container representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the `ldp:membershipResource`, and whose object is the LDPC's `membership-constant-URI`. Commonly the LDPC's URI is the `membership-constant-URI`, but LDP does not require this.

LDP Direct Containers whose membership triple pattern is `( membership-constant-URI , membership-predicate , member-derived-URI )` MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is `ldp:hasMemberRelation`, and whose object is the URI of `membership-predicate`.

LDP Direct Containers whose membership triple pattern is `( member-derived-URI , membership-predicate , membership-constant-URI )` MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is `ldp:isMemberOfRelation`, and whose object is the URI of `membership-predicate`.

LDP servers remove the resource identified by the `Request-URI` in response to a successful HTTP `DELETE` request. After such a request, a subsequent HTTP `GET` on the same `Request-URI` usually results in a 404 (Not found) or 410 (Gone) status code, although HTTP allows others.

LDP servers can implement HTTP `PATCH` to allow modifications, especially partial replacement, of their resources. No minimal set of patch document formats is mandated by this document or by the definition of `PATCH` [[RFC5789]].

When the `Content-Type` request header is absent from a request, LDP servers might infer the content type by inspecting the entity body contents ([[RFC7231]] section 3.1.1.5).

The state of a LDPR can have more than one triple with an `rdf:type` predicate.

The syntax for `Accept-Post`, using the ABNF syntax defined in Section 1.2 of [[!RFC7231]], is:

The `include` hint defines a subset of a LDPR's content that a client would like included in a representation. The syntax for the `include` parameter of the HTTP `Prefer` request header's `return=representation` preference [[!RFC7240]] is:

The `omit` hint defines a subset of a LDPR's content that a client would like omitted from a representation. The syntax for the `omit` parameter of the HTTP `Prefer` request header's `return=representation` preference [[!RFC7240]] is:

This specification defines the following URIs for clients to use with `include` and `omit` parameters. It assigns no meaning to other URIs, although other specifications MAY do so.