Linked Data Platform 1.0 W3C Last Call Working Draft 30 July 2013 This version: http://www.w3.org/TR/2013/WD-ldp-20130730/ Latest published version: http://www.w3.org/TR/ldp/ Latest editor's draft: http://www.w3.org/2012/ldp/hg/ldp.html Previous version: http://www.w3.org/TR/2013/WD-ldp-20130307/ Editors: Steve Speicher , IBM Corporation John Arwe , IBM Corporation Ashok Malhotra , Oracle Corporation Copyright © 2013 W3C ® ( MIT , ERCIM , Keio , Beihang ), All Rights Reserved. W3C liability , trademark and document use rules apply. Abstract
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. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. This document was published by the Linked Data Platform Working Group as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-ldp-comments@w3.org ( subscribe , archives ). The Last Call period ends 02 September 2013. All comments are welcome. Publication as a Last Call Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy . Table of Contents 1. Introduction 2. Terminology 2.1 Conventions Used in This Document 3. Conformance 4. Linked Data Platform Resources 4.1 Informative 4.2 General 4.3 HTTP GET 4.4 HTTP POST 4.5 HTTP PUT 4.6 HTTP DELETE 4.7 HTTP HEAD 4.8 HTTP PATCH 4.9 HTTP OPTIONS 4.10 Paging 4.10.1 Introduction 4.10.2 HTTP GET 4.10.3 HTTP OPTIONS 4.11 Resource Inlining: Representing Multiple Resources in a Response 4.11.1 Introduction 4.11.2 Use with Care 4.11.3 HTTP GET 5. Linked Data Platform Containers 5.1 Informative 5.2 General 5.3 HTTP GET 5.4 HTTP POST 5.5 HTTP PUT 5.6 HTTP DELETE 5.7 HTTP HEAD 5.8 HTTP PATCH 5.9 HTTP OPTIONS 5.10 Member Inlining: Returning All of a Container Page's Members in a Response 5.10.1 Introduction 5.10.2 HTTP GET 6. HTTP Header Definitions 6.1 The Accept-Post Response Header A. Acknowledgements B. References B.1 Normative references B.2 Informative references
1.

Introduction This section is non-normative.

This document specification describes the use of HTTP for accessing, updating, creating and deleting resources from servers that expose their resources as Linked Data.  It  It provides clarifications and extensions of the four rules of Linked Data [ LINKED-DATA ]: [[LINKED-DATA]]:

1.
  1. Use URIs as names for things 2.
  2. Use HTTP URIs so that people can look up those names 3.
  3. When someone looks up a URI, provide useful information, using the standards ( RDF *, (RDF*, SPARQL ) 4.
  4. Include links to other URIs, so that they can discover more things

This specification discusses standard HTTP and RDF techniques used when constructing clients and servers that create, read, and write Linked Data Platform Resources . A companion document discusses best practices that you should use, and anti-patterns you should avoid, when constructing these clients and servers that read and write Linked Data servers.

This specification provides a widely re-usable pattern to deal with large resources. Depending on the server’s capabilities, a GET request on a resource can be redirected to a subset of the resource (one page) , that provides access to subsequent pages (see ).

A This specification defines a special type of Linked Data Platform Resource is : a Container . Containers are very useful in building application models involving collections of resources, often homogeneous resources. ones. For example, universities offer a collection of classes and have a collection of faculty members, each faculty member teaches a collection of courses, etc. and so on. This specification discusses how to work with containers. Resources can be added to containers in several ways. As a special case, members can both be created and added to a container by overloading the using standard HTTP operations like POST operation (see section 5.4 ). Another contribution of this specification is how to deal with large amounts of data. Depending on the server’s capabilities, a GET request on a Linked Data Platform Resource returns a set of pages and uses a convention to access any subsequent page (see section 4.10 ).

The intention of this document specification is to enable additional rules and layered groupings of rules as additional specifications. The scope is intentionally narrow to provide a set of key rules for reading and writing Linked Data that most, if not all, other specifications will depend upon and implementations will support.

For context and background, it could be useful to read Linked Data Platform Use Case and Requirements [[LDP-UCR]] and 2. .

Terminology

Terminology is based on W3C 's W3C's Architecture of the World Wide Web [ WEBARCH ] [[WEBARCH]] and Hyper-text Transfer Protocol [ HTTP11 ]. [[HTTP11]].

Link
A relationship between two resources when one resource (representation) refers to the other resource by means of a URI [ WEBARCH ]. [[WEBARCH]].

Linked Data
As defined by Tim Berners-Lee [ LINKED-DATA ]. Linked Data Platform Resource ( LDPR ) HTTP resource whose state is represented in RDF that conforms to the simple lifecycle patterns and conventions in section 4. . Linked Data Platform Container ( LDPC ) An LDPR representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI that responds to client requests for creation, modification, and enumeration of its members. [[LINKED-DATA]].

Client
A program that establishes connections for the purpose of sending requests [ HTTP11 ]. [[HTTP11]].

Server
An application program that accepts connections in order to service requests by sending back responses.

Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request [ [[HTTP11]].

HTTP11 Linked Data Platform Resource ( LDPR )
A HTTP resource whose state is represented in any way that conforms to the simple lifecycle patterns and conventions in .

Linked Data Platform RDF Resource ( LDP-RR )
An LDPR whose state is represented in RDF, corresponding to an RDF named graph [[rdf11-concepts]].

].

Linked Data Platform Binary Resource ( LDP-BR )
A LDPR whose state is not represented in RDF. These are binary or text documents that do not have useful RDF representations.

Linked Data Platform Container ( LDPC )
An LDPR representing a collection of member resources and/or contained documents (information resources [[!WEBARCH]]) that responds to client requests for creation, modification, and/or enumeration of its members and documents, and that conforms to the simple lifecycle patterns and conventions in .

Linked Data Platform Basic Container ( LDP-BC )
A LDPC that uses a single pre-defined predicate to link to both its contained and member documents (information resources) [[!WEBARCH]].

Linked Data Platform Direct Container ( LDP-DC )
A LDPC that has the flexibility of choosing what form its membership triples take, and allows members to be any resources [[!WEBARCH]], not only documents.

Linked Data Platform Indirect Container ( LDP-IC )
A LDPC that is similar to a LDP-DC and is capable of accepting creation requests that result in members being added based on the content of its contained documents rather than the URIs assigned to those documents.

Membership
The relationship linking an LDP-RR (LDPCs are also LDP-RRs) and its member LDPRs. There often is a linked LDPC that assists with managing the member LDPRs.

Membership triples
A set of triples in an LDPC 's LDPC's state that lists its members. The A container's membership triples all have one of the following patterns:
membership-constant-URI membership-predicate member-derived-URI
member-derived-URI membership-predicate membership-constant-URI
The difference between the two is simply which position member-derived-URI occupies, which is usually driven by the choice of membership-predicate . Most predicates have a natural forward direction inherent in their name, and existing vocabularies contain useful examples that read naturally in each direction. ldp:member and dcterms:isPartOf are representative examples.

Each container all have exposes properties (see ) that allow clients to determine which pattern it uses, what the same subject actual membership-predicate and predicate, membership-constant-URI values are, and (for containers that allow the objects creation of new members) what value is used for the membership triples identify member-derived-URI based on the container's members. client's input to the creation process.

Membership subject predicate
The subject predicate of all a LDPC 's LDPC's membership triples .

Membership predicate Containment
The predicate relationship binding an LDPC to LDPRs whose lifecycle it controls and is aware of. The lifecycle of all the contained LDPR is limited by the lifecycle of the containing LDPC; that is, a contained LDPR cannot be created (through LDP-defined means) before its containing LDPC 's membership triples . exists.

Page resource Containment triples
A type set of LDPR triples in an LDPC's state, maintained by the LDPC, that lists documents created by the LDPC but not yet deleted. These triples always have the form: ( LDPC URI, ldp:contains , document-URI ) .

Empty-container triples
The portion of an LDPC's state that would be present when the container is associated empty. Currently, this definition is equivalent to another LDPR all the LDPC's triples minus its containment triples and whose representation includes a subset minus its membership triples, but if future versions of LDP define additional classes of the triples in the associated LDPR . then this definition would expand to subtract out those classes as well.

Non-member Paged resource
A resource associated with a LDPC by LDP-RR whose representation may be too large to fit in a server single HTTP response, for the purpose of enabling clients to retrieve which an LDP server offers a subset sequence of single-page LDP-RRs . When the LDPC 's state, namely the subset that omits representations of the LDPC 's membership triples. In other words, sequence's resources are combined by a client, the union client has a (potentially incomplete or incoherent) copy of the non-member paged resource's state state. If a paged resource P is a LDP-RR and is broken into a sequence of pages (single-page resources) P 1 , P 2 , ...,P n , the representation of each P i contains a subset of the LDPC 's membership triples in P . LDP allows paging of resources other than LDP-RRs , but does not specify how clients combine their representations. See for additional details. For readers familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed. Any resource could be considered to be a paged resource consisting of exactly equals the LDPC 's state. one page, although there is no known advantage in doing so.

Resource inlining Single-page resource
The practice One of responding to a HTTP GET request made to a request URI sequence of related LDP-RRs R P 0 1 , P 2 , ...,P n , each of which contains a subset of the state of another resource P . P is called the paged resource. For readers familiar with paged feeds [[RFC5005]], a representation single-page resource is similar to a feed document and the same coherency/completeness considerations apply. LDP provides no guarantees that includes the state sequence is stable .

Note: the choice of R 0 , terms was designed to help authors and readers clearly differentiate between the entire resource being paged state of resources accessed through , and the other individual page resources request URI(s) , in cases where both are mentioned in close proximity.

first page link
A link to the first single-page resource of a paged resource R P . Syntactically, a HTTP Link < P 1 ... >; rel='first' header [[!RFC5988]].

next page link
A link to the next single-page resource of a paged resource R P . Syntactically, a HTTP Link < P n i , and assertions from the server identifying >; rel='next' header [[!RFC5988]] where the additional resources whose entire state has been provided. target URI is R P 1 i=2...n ... .

last page link
A link to the last single-page resource of a paged resource R P . Syntactically, a HTTP Link < P n identify the inlined resource(s). See section 4.11 for details. >; rel='last' header [[!RFC5988]].

Member inlining previous page link
A special case of link to the previous single-page resource inlining , where all members of a container on paged resource P . Syntactically, a given page are inlined. The response page may or may not include all of HTTP Link < P i >; rel='prev' header [[!RFC5988]] where the container's members. See section 5.10 for details. target URI is P i=1...n-1 .

2.1

Conventions Used in This Document

Sample resource representations are provided in text/turtle format [ TURTLE ]. [[TURTLE]].

Commonly used namespace prefixes:

@prefix dcterms: <http://purl.org/dc/terms/>. @prefix rdf:    <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#>. @prefix ldp:     <http://www.w3.org/ns/ldp#>. @prefix xsd:    <http://www.w3.org/2001/XMLSchema#>.
     @prefix dcterms: <http://purl.org/dc/terms/>.
        @prefix foaf:     <http://xmlns.com/foaf/0.1/>.
        @prefix rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
        @prefix ldp:     <http://www.w3.org/ns/ldp#>.
        @prefix xsd:     <http://www.w3.org/2001/XMLSchema#>.

3. Conformance As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative. The key words MUST , MUST NOT , REQUIRED , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL in this specification are to be interpreted as described in [ RFC2119 ].

The status of the sections of Linked Data Platform 1.0 (this document) is as follows:

A conforming LDP server client is an application program that processes HTTP requests and generates a conforming HTTP responses client [[!HTTP11]] that conform to follows the rules defined by LDP in section 4. Linked Data Platform Resources and section 5. Linked Data Platform Containers .

A conforming LDP client server is an application program that generates HTTP requests and processes a conforming HTTP responses server [[!HTTP11]] that conform to follows the rules defined by LDP in section 4. Linked Data Platform Resources when it is serving LDPRs, and section 5. also when it is serving LDPCs. LDP does not constrain its behavior when serving other HTTP resources.

Linked Data Platform Containers Clients

All of the following are conformance rules for LDP Clients .

General

In the absence of special knowledge of the application or domain, LDP clients MUST assume that any LDP-RR can have multiple values for rdf:type .

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

4. LDP clients SHOULD always assume that the set of predicates for a LDP-RR 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-RR is not limited to any pre-defined set.

A LDP client MUST preserve all triples retrieved from an LDP-RR 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-RRs .

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

Linked Data Platform Resources

Introduction

4.1 Informative This section is non-normative.

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 LDPR servers. 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 ]; [[LINKED-DATA]]; others address additional needs.

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

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

The following sections define the conformance rules and guidelines for use of LDPRs . LDP servers when serving LDPRs. This document also explains how to include information about each member in the resource’s own representation and how to paginate the resource a server paginates an LDP-RR's representation if it gets too big. Companion non-normative documents describe additional guidelines for use when interacting with LDPRs.

An LDP server manages two kinds of LDPRs , those resources who whose state is represented using RDF (LDP-RR) and those using other formats (LDP-BR). LDP-RRs 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 [[!RDF-CONCEPTS]]. LDP-BRs are almost anything on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RRs hold metadata associated with LDP-BRs in some cases.

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

The LDP-BRs and LDP-RRs are simply sub-types of LDPRs, as illustrated in .

Class Diagram of Linked Data Platform Resource
Class relationship of types of LDPRs

General 4.2.1 LDPR

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

]. 4.2.2 LDPR LDP servers MUST provide an RDF representation for LDPRs . LDP-RRs . The HTTP Request-URI of the LDPR LDP-RR is typically the subject of most triples in the response. 4.2.3 LDPR

LDP servers MAY host a mixture of LDPRs LDPRs, LDP-RRs and non- LDPRs . LDP-BRs . For example, it is common for LDPR LDP servers to need to host binary or text resources that do not have useful RDF representations. 4.2.4 LDPRs

LDP-RRs 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. 4.2.4.1 LDPR

LDP-RRs predicates SHOULD use standard vocabularies such as Dublin Core [ DC-TERMS ], [[!DC-TERMS]], RDF [ RDF-CONCEPTS ] [[!RDF-CONCEPTS]] and RDF Schema [ RDF-SCHEMA ], [[!RDF-SCHEMA]], whenever possible. 4.2.5 LDPR

LDP-RRs representations SHOULD have at least one rdf:type set explicitly.  This  This makes the representations much more useful to client applications that don’t support inferencing. 4.2.6 LDPR servers MAY support standard representations beyond those necessary to conform to this specification. These could be other RDF formats, like N3 or NTriples, but non- RDF formats like HTML [ HTML401 ] and JSON [ RFC4627 ] would likely be common. 4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in this document, for example through application-specific means, SPARQL UPDATE, etc. [ SPARQL-UPDATE

], as long as those methods do not conflict with this specification's normative requirements. 4.2.8 LDPR LDP server responses MUST use entity tags (either weak or strong ones) as response ETag header values. 4.2.9 LDPR

LDP servers SHOULD enable simple creation and modification of exposing LDPRs . It is common for LDPR servers to put restrictions on representations – for example, the range of rdf:type predicates, datatypes of the objects of predicates, and the number of occurrences of predicates in an LDPR , but servers SHOULD minimize those restrictions.  Enforcement of more complex constraints will greatly restrict the set of clients that can modify resources. For some server applications, excessive constraints on modification of resources may be required. 4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource http://www.w3.org/ns/ldp#Resource , and a link relation type of type (that is, rel="type" rel='type' ) in all responses to requests made to the resource's LDPR's HTTP Request-URI . This is notionally equivalent to the presence of a (subject-URI, rdf:type , ldp:Resource ) triple in the resource.

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 introspect inspect dynamically at run-time. Conservative clients should note that This is not equivalent to the presence of a (subject-URI, rdf:type , ldp:Resource ) triple in an RDF resource. The presence of this 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 , has an RDF representation , and so on, which is not true of all Web resources served as RDF media types.

Note: A LDP server can host a mixture of LDPRs and other resources , 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 . LDPRs. Each HTTP Request-URI needs to be individually introspected by a conservative client, inspected, in the absence of outside information. 4.2.11 LDPR

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 [ RDF-CONCEPTS ]. [[!RDF-CONCEPTS]]. The practical implication is that all content defined by LDP must be explicitly represented. 4.2.12 LDPR

LDP servers MUST assign the default base-URI for [ RFC3987 ] [[!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.

4.3 LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with rel='describedby' [[!POWDER-DR]] 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; as stated in [[POWDER-DR]], the target might (or might not) be a POWDER document. Natural language constraint documents are therefore permitted, although machine-readable ones facilitate better client interactions.

LDP servers SHOULD allow clients to retrieve large LDP-RRs in pages. See for additional requirements associated with paged resources .

LDP servers MAY treat any resource (LDP-RR or not) as a paged resource . See for additional details.

HTTP GET 4.3.1 LDPR

LDP servers MUST support the HTTP GET Method for LDPRs . 4.3.2 LDPR LDPRs.

LDP servers MUST support the HTTP response headers defined in section 4.9 . 4.3.3 LDPR

LDP servers SHOULD MUST provide a text/turtle representation of the requested LDPR [ TURTLE ]. 4.3.4 LDPR servers MAY provide representations of the requested LDPR beyond those necessary to conform to this specification, using standard HTTP content negotiation ([ HTTP11 LDP-RR ] Section 12 - Content Negotiation). If the client does not indicate a preference, text/turtle SHOULD be returned. 4.3.5 In the absence of special knowledge of the application or domain, LDPR clients MUST assume that any LDPR can have multiple values for rdf:type . 4.3.6 In the absence of special knowledge of the application or domain, LDPR clients MUST assume that the rdf:type values of a given LDPR can change over time. [[!TURTLE]].

4.4

HTTP POST

This specification adds no new requirements on HTTP POST for LDPRs even when the LDPR supports that method. This specification does not impose any new requirement to support that method, and [ HTTP11 ] [[!HTTP11]] makes it optional.

Creation of LDPRs Clients can be done create LDPRs via POST ( section 5.4 ) or PUT ( section 5.5 ) to a LDPC , LDPC, see those sections for more details. Any server-imposed constraints on LDPR creation or update must be advertised to clients.

4.5

HTTP PUT

This Per [HTTP11], this HTTP method is optional and this specification does not require LDP servers to support it. When a LDP server chooses to support this method, this specification imposes the following new requirements on HTTP PUT for LDPRs only when the LDPRs.

Any server-imposed constraints on LDPR supports that method. This specification does not impose any new requirement to support that method, and [ HTTP11 creation or update must be advertised ] makes it optional. to clients.

4.5.1

If a HTTP PUT is performed accepted on an existing resource, LDPR LDP servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request. LDPR LDP servers MAY ignore server managed properties such as dcterms:modified and dcterms:creator if they are not under client control. Any LDPR 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 . 4.5.2 LDPR

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

Non-normative note: Clients might provide triples 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-controlled triples are identical on the GET response and the subsequent PUT request.

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. LDPR LDP servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions. LDPR 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 [ HTTP11 ]. LDPR [[!HTTP11]]. 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 ]. 4.5.3 LDPR clients SHOULD always assume that the set of predicates for a resource of a particular type at [[!RFC6585]].

If 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 resource otherwise valid HTTP PUT request is not limited to any pre-defined set. 4.5.4 LDPR clients SHOULD assume received that an LDPR server could discard contains triples whose predicates the server does not recognize or otherwise chooses not to persist. In other words, LDPR persist, e.g. unknown content, LDP servers MAY restrict themselves to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates when their intent is to perform respond with an appropriate 4xx range status code [[HTTP11]]. LDP servers SHOULD provide a later HTTP PUT to update the resource. 4.5.5 An LDPR client MUST preserve all corresponding response body containing information about which triples retrieved using HTTP GET that it doesn’t change whether it understands could not be persisted. The format of the predicates or not, when its intent 4xx response body 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 not constrained by LDP.

]. 4.5.6 LDPR LDP servers MAY choose to allow the creation of new resources using HTTP PUT . 4.5.7 LDPR

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 LPDRs. LDPRs.

4.6

HTTP DELETE

This specification imposes the following new requirements on Per [HTTP11], this HTTP DELETE for LDPRs only when the LDPR supports that method. This method is optional and this specification does not impose any new requirement require LDP servers to support that it. When a LDP server chooses to support this method, and [ HTTP11 ] makes it optional. this specification imposes the following new requirements for LDPRs.

Additional requirements on HTTP DELETE of LDPRs within containers can be found in section 5.6 .

4.6.1 LDPR servers MUST remove the resource identified by the Request-URI . After a successful HTTP DELETE , a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code. Clients SHOULD note that servers MAY reuse a URI under some circumstances. 4.6.2 LDPR servers MAY alter the state of other resources as a result of an HTTP DELETE request. For example, it is acceptable for the server to remove triples from other resources whose subject or object is the deleted resource. It is also acceptable and common for LDPR servers to not do this – behavior is server application specific.
4.7

HTTP HEAD

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

4.7.1 LDPR

LDP servers MUST support the HTTP HEAD method.

4.8

HTTP PATCH

This specification imposes the following new requirements on Per [HTTP11], this HTTP PATCH for LDPRs only when the LDPR supports that method. This method is optional and this specification does not impose any new requirement require LDP servers to support that it. When a LDP server chooses to support this method, and [ HTTP11 ] makes it optional. this specification imposes the following new requirements for LDPRs.

4.8.1

Any server-imposed constraints on LDPR servers MAY implement HTTP PATCH to allow modifications, especially partial replacement, of their resources [ RFC5789 creation or update must be advertised to clients.

]. No minimal set of patch document formats is mandated by this document. 4.8.2 LDPR 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 LPDRs. 4.8.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH . POST (to an LDPC ) LDPC) and/or PUT should be used as the standard way to create new LDPRs . 4.8.4 LDPR LDPRs.

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

4.9

HTTP OPTIONS

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

4.9.1 LDPR

LDP servers MUST support the HTTP OPTIONS method. 4.9.2 LDPR

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

4.10

Paging 4.10.1

Introduction This section is non-normative.

It sometimes happens that a resource is too large to reasonably transmit its representation in a single HTTP response. This will be especially true if the resource representation includes many triples both from its own representation and from the representations of any inlined resources . A client could anticipate that a resource will be too large - for example, a client tool that accesses defects may assume that an individual defect will usually be of sufficiently constrained size that it makes sense to request all of it at once, but that the container of all the defects ever created will typically be too big. Alternatively, a server could recognize that a resource that has been requested is too big to return in a single message. To address this problem, LDPRs servers should support a technique called Paging.  Paging can be achieved with   When a client retrieves such a simple RDF pattern. For each resource, <resourceURL> , we define the server redirects the client to a new 'first page' resource. In this example, "first page" resource, and includes in its URL will be <resourceURL>?firstPage , but servers are free response a link to construct the URL as they see fit. next part of the resource's state, all at a URLs of the server's choosing. The triples in the representation of the each page of an LDPR are typically a subset of the triples in from the paged resource - same subject, predicate and object. .

LDPR LDP servers may respond to requests for a resource by redirecting the client to the first page of the resource – using and, with that, returning a 303 “See Other” redirect to Link <next-page-URL>;type='next' header containing the actual URL for the page resource. Alternatively, clients may introspect the resource next page. Clients inspect each response for a paged representation the link header to see if additional pages are available; paging does not affect the choice of HTTP status code. Note that paging is lossy, as described in [[RFC5005]], and use it preferentially when available. so (as stated there) clients should not make any assumptions about a set of pages being a complete or coherent snapshot of a resource's state.

Looking at an example resource representing Example Co.'s customer relationship data, identified by the URI http://example.org/customer-relations , we’ll split the response across two pages.   To find the URL of the first page, the   The client makes a retrieves OPTIONS request to the resource's URL, http://example.org/customer-relations , and in the response looks for a HTTP server responds with status code Link 333 (Returning Related) header with , a rel="first" Location: http://example.org/customer-relations?page1 ; the target URI in the header is the URL of the first page resource. The client then requests HTTP response header, and the first page as http://example.org/customer-relations?firstPage : following representation:

# The following is the representation of # http://example.org/customer-relations?firstPage
# The following is the representation of
#    http://example.org/customer-relations?page1
#    Requests on the URI will result in responses that include the following HTTP header
#       Link: <http://example.org/customer-relations?p=2>; rel='next'
#    This Link header is how clients discover the URI of the next page in sequence,
#    and that the resource supports paging.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@base <http://example.org/customer-relations>.

<http://example.org/customer-relations>

<>

   a o:CustomerRelations;
   dcterms:title "The customer information for Example Co.";
   o:client <client#JohnZSmith>, <client#BettyASmith>, <client#JoanRSmith>. 
<http://example.org/customer-relations?firstPage>
   a ldp:Page;
   ldp:pageOf <http://example.org/customer-relations>;
   ldp:nextPage <http://example.org/customer-relations?p=2>.

   dcterms:title "The customer information for Example Co.";
   o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>. 

<client#JohnZSmith>
   a foaf:Person;

<#JohnZSmith>
   a foaf:Person;

   o:status o:ActiveCustomer;
   foaf:name "John Z. Smith".
<client#BettyASmith>
   a foaf:Person;

   foaf:name "John Z. Smith".
<#BettyASmith>
   a foaf:Person;

   o:status o:PreviousCustomer;
   foaf:name "Betty A. Smith".
 <client#BettyASmith>
   a foaf:Person;

   foaf:name "Betty A. Smith".
 <#JoanRSmith>
   a foaf:Person;

   o:status o:PotentialCustomer;
 
foaf:name
"Joan
R.
Smith".

   foaf:name "Joan R. Smith".

Because the server includes a Link: <http://example.org/customer-relations?p=2>; rel='next' response header, and the status code is 3xx ( 333 (Returning Related) in this case), the client knows that more data exists and where to find it. The server determines the size of the pages using application specific methods not defined within this specificiation. Note also, the actual name for the query parameter (such as ?p=2) The next page link's target URI is also defined by the server and not this specification.

The following example is the result of retrieving the representation for the next page: page; the server responds with status code 200 (OK) and the following representation:

# The following is the representation of
# The following is the representation of

#  http://example.org/customer-relations?p=2
#
#  There is no "next" Link in the server's response, so this is the final page.
#

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@base <http://example.org/customer-relations>.

<http://example.org/customer-relations>
   o:client <client#GlenWSmith>, <client#AlfredESmith>. 

<>
   o:client <#GlenWSmith>, <#AlfredESmith>. 

 
<http://example.org/customer-relations?p=2>
   a ldp:Page;
   ldp:pageOf <http://example.org/customer-relations>;
   ldp:nextPage rdf:nil.
<client#GlenWSmith>
   a foaf:Person;

<#GlenWSmith>
   a foaf:Person;

   o:status o:ActiveCustomer, o:GoldCustomer;
   foaf:name "Glen W. Smith".

   foaf:name "Glen W. Smith".

<client#AlfredESmith>
   a foaf:Person;

<#AlfredESmith>
   a foaf:Person;

   o:status o:ActiveCustomer, o:BronzeCustomer;
 
foaf:name
"Alfred
E.
Smith".

   foaf:name "Alfred E. Smith".
 

In this example, there are only two customers provided in the final page.  To  To indicate this is the last page, a value of rdf:nil is used for the server omits the ldp:nextPage Link: rel='next' predicate header in its response.

As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client that it knows the entire state of the server. For example, after the server constructs the the first page resource. representation, another actor could delete client#BettyASmith from the server.

4.10.2

HTTP GET

In addition to the requirements set forth in section 4.3 on HTTP GET , LDPR LDP servers that support paging must also follow the requirements in this section for all paged resources and their associated single-page resources .

4.10.2.1 LDPR

LDP servers MAY add single-page resources to a paged resource's sequence over time, but SHOULD allow clients only add pages to retrieve large LDPRs the end of a sequence.

Non-normative note: As a result, clients retrieving any single-page resource several times can observe its place in the sequence change as the state of the paged resource changes. For example, a nominally last page's server might provide a next page link when the page is retrieved. Similar situations arise when the page sequence crosses server boundaries; server A might host the initial portion of a sequence that links to the last page server A is aware of, hosted on server B, and server B might extend the sequence of pages. In

LDP servers MAY provide a first page link when responding to requests with any single-page resource as the Request-URI .

LDP servers MAY provide a last page link in responses to GET requests with an LDPR any single-page resource as the Request-URI , LDPR .

LDP servers that support paging SHOULD MUST provide an HTTP Link header whose target URI is the first a next page resource, and whose link relation type is in responses to first GET [ RFC5988 requests with any single-page resource ]. other than the final page as the Request-URI . This is the mechanism by which clients can discover the URL of the first next page. If no such Link header is present, then conservative clients will assume that the LDPR does not support paging. For example, if there is

LDP servers MUST NOT provide a LDPR with URL <resourceURL> that supports paging and whose first next page URL is <resourceURL>?theFirstPage , then the corresponding link header would be in responses to Link: <?theFirstPage>;rel="first" . The representation for any page, including the first, will include the URL for GET requests with the next page. See section 4.10 final single-page resource for additional details. 4.10.2.2 LDPR servers MAY split as the response representation of any LDPR . Request-URI . This is known as server-initiated paging. See section 4.10 for additional details. 4.10.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR the mechanism by redirecting which clients can discover the client to end of the first page resource using sequence as currently known by the server.

LDP servers MAY provide a previous page link in responses to 303 See Other GET response requests with an HTTP Location header providing the first page any single-page resource URL. 4.10.2.4 LDPR servers that support paging MUST include a representation for other than the first page resource. 4.10.2.4.1 The page resource representation MUST have one triple with the subject of as the page, predicate of ldp:nextPage and object being Request-URI . This is one mechanism by which clients can discover the URL for of the subsequent previous page. <http://example.org/customer-relations?firstPage> ldp:nextPage <http://example.org/customer-relations?p=2> .

4.10.2.4.2 The last page resource representation LDP servers MUST have one triple with the subject of the last page, predicate of ldp:nextPage and object being rdf:nil . <http://example.org/customer-relations?p=2> ldp:nextPage rdf:nil . 4.10.2.4.3 The NOT provide a previous page resource representation SHOULD have one triple link in responses to indicate its type, whose subject is the URL of the page, whose predicate is rdf:type GET and object is ldp:Page . It also SHOULD have 1 triple to indicate requests with the first single-page resource it is paging, whose  subject is the URL of as the page, predicate is ldp:pageOf , and object Request-URI . This is one mechanism by which clients can discover the URL beginning of the LDPR . <http://example.org/customer-relations?firstPage> rdf:type ldp:Page; ldp:pageOf <http://example.org/customer-relations>. page sequence as currently known by the server.

4.10.3 HTTP OPTIONS 4.10.3.1 LDPR LDP servers MUST indicate their support for client-initiated paging by responding to a provide an HTTP OPTIONS Link request on the LDPR ’s URL with the HTTP response header for link relations using the header name of whose target URI is Link http://www.w3.org/ns/ldp#Page , and whose link relation type is first type [ RFC5988 ]. 4.11 Resource Inlining: Representing Multiple Resources [[!RFC5988]] in responses to GET requests with any single-page resource as the Request-URI . This is one mechanism by which clients know that the resource is one of a Response sequence of pages.

Feature At Risk

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

  • The addition of resource inlining to save application latency and server/network load in controlled environments. Feedback, both positive and negative, is invited by sending email to the mailing list in Status of This Document . 4.11.1 Introduction

    This section is non-normative. Servers A TAG discussion has started, whose resources are relatively granular may wish to optimistically provide more information in a response than what the client actually requested, in order goal is to reduce the average number of client application HTTP flows. LDP provides some basic building blocks to enable this, that implementations can re-use to build complete solutions, and they may serve as complete solutions in applications with sufficient controls on resource content. These building blocks are resource inlining and member inlining . LDP does not provide clients with any way to detect whether or not the server is capable of inlining (all its resources or any specific resource), nor does it provide clients with any way need for two request-response round trips down to influence which (if any) resources are inlined in any given response. Servers can return extra triples on any response, but fail one when retrieving what turns out to meet be the definition first page of resource inlining , a paged resource, by either returning defining a subset of new HTTP response code in the other resource(s) triples 2xx or by failing to assert 3xx class that all triples were included (even through they were). Clients might still find the extra information useful, but the only way for clients to be sure they had all available information would be to make allow a HTTP server to respond to GET request-uri request against all the other resource(s). In some applications, knowing that these requests are unnecessary saves significant latency and server/network load. 4.11.2 Use with Care This section is non-normative. The building blocks LDP provides can only be safely used if certain assumptions hold. Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case — so if you care about any representation of the following in a given application, your server should avoid returning any triples beyond those found at the HTTP Request-URI . Provenance is lost: because RDF graphs from multiple HTTP resources are merged in the response without attributing each statement to its originating graph (i.e. without quotation), it first page (whose URI is impossible for first-page-uri , not request-uri ) of a client to reliably know which triples came from which HTTP resource(s). A general solution allowing quotation is RDF Datasets; that is expected to be standardized independently, and can be used in these cases once it is available. multi-page response.

  • The response may contain contradictions that are trivially obvious (or subtle), and those may or may not be a problem at the application level. For a trivial example, two triples may have identical subjects and predicates but different objects: "75F is too hot"; "75F is too cold". Again, quotation via RDF Datasets (or any equivalent mechanism) is believed to provide a long term solution once standardized. 4.11.3 HTTP GET In addition to the requirements set forth in other sections, LDPR servers that support resource inlining must also follow the requirements in purposes of drafting this section. 4.11.3.1 LDPR servers section, we assume that support resource inlining MUST include a ldp:Page resource in the representation describing the set of inlined resources, whether or not the representation contains subsequent pages. The ldp:Page resource conceptually contains metadata about the representation; it new code's value is usually not part of the HTTP resource's state, 333 (Returning Related) , an LDP extrapolation from TAG discussions, and its presence does not indicate that definition is given by Henry Thompson's strawman , with the LDPR server supports paging in general. LDPR substitution of 333 for 2xx. Note: nothing prevents servers that include the or clients from using ldp:Page 303 See Other resource responses to requests for inlining paged resources . The only significant difference between 303 and also support paging MUST use 333 responses is the same ldp:Page resource extra round trip required for the triples required by both, in order to minimize client code complexity. The ldp:Page resource's triples are the LDP-defined means by which the servers communicate to LDP clients retrieve the set representation of HTTP resources whose state the first page when using 303.

  • Once LDP is included in a representation, allowing clients Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF, working with the W3C Director, to avoid HTTP GET requests for them. 4.11.3.2 LDPR servers that support resource inlining MUST include either use the ldp:Page resource described newly defined response code as documented in this section 4.11.3.1 one triple for each inlined resource, whose subject is the ldp:Page resource URI, whose predicate is ldp:inlinedResource , and whose object is the HTTP or to revert to a classic Request-URI 303 of an inlined resource [ response pattern.

HTTP11 LDP servers ]. 4.11.3.3 LDPR clients SHOULD avoid making respond with HTTP status code 333 (Returning Related) to successful GET requests against with any paged resource whose HTTP as the Request-URI is the object of a triple of the form described in section 4.11.3.2 , unless there are application-specific reasons for doing so. Clients should note that by the time the representation is received, the actual state of , although any inlined resource(s) may have changed due appropriate code MAY be used.

HTTP OPTIONS

In addition to subsequent requests. 4.11.3.4 LDPR clients MUST NOT assume that LDPR representations lacking a ldp:Page resource or lacking the triple described requirements set forth in section 4.11.3.2 contain all the triples for any resource(s) listed in the representation whose HTTP Request-URI differs from the on HTTP Request-URI used by OPTIONS , LDP servers that support paging must also follow the client. The representation might requirements in fact contain this section for all such triples, or some subset of them, and paged resources . Note that might or might not be completely adequate for the client's intended usage, but an LDP client has no way to discern only requires enough from such OPTIONS for discovery of paging support on a representation resource, which interpretation is accurate. considerably less than is required for HTTP GET . This lowers server implementation effort.

5.

Linked Data Platform Containers

Introduction

5.1 Informative This section is non-normative.

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:

  1. To which URLs can I POST to create new resources?
  2. Where can I GET a list of existing resources?
  3. How is the order of the container entries expressed?
  4. How do I get information about the members along with the container?
  5. How can I ensure the resource data is easy to query?

This document defines the representation and behavior of containers that address these issues. The set of members of a container is defined by a set of triples in its representation (and state) called the membership triples. 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 subject predicate, called the membership predicate, and predicate either the subject or the object is also a consistent value – the objects remaining position of the membership triples (the one that varies) define the members of the container. The subject of the membership triples is called the membership subject and the predicate is called the membership predicate. In the simplest cases, the membership subject consistent value will be the LDPC resource itself, 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 rdfs:member ldp:member predicate.

This document includes a set of guidelines for using POST to create creating new resources and add adding them to the list of members of a container. It goes on to explain how to learn about a set of related resources, regardless of how they may have been were created using POST or through other means. added to the container's membership. It also defines behavior when POST created resources are deleted, to clean up created using a container membership, and are later deleted; deleting containers removes membership information and possibly perform 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):

# The following is the representation of #    http://example.org/container1/
# The following is the representation of
#    http://example.org/c1/
# @base <http://example.org/c1/>

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

@prefix ldp: <http://www.w3.org/ns/ldp#>.
<>
   a ldp:Container;
   ldp:membershipSubject <>
   ldp:membershipPredicate rdfs:member;
   ldp:membershipObject ldp:MemberSubject;
   dcterms:title "A very simple container";
 
rdfs:member
<member1>,
<member2>,
<member3>.

   a ldp:Container, ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains <r1>, <r2>, <r3>.

Sample Linked Data Platform Basic Container
Sample of Linked Data Platform Basic Container

This example is very straightforward - the membership and containment predicate is are both rdfs:member ldp:contains and the other consistent membership subject value is the container itself. container's URI, occurring in the subject position of the triples. A POST to this container will create a new resource and add it to the list of members by adding a new membership triple to the container. This type of container is also refered to as LDP Basic Container .

Sometimes it is useful to use a subject other than the container itself as the consistent membership subject and value, and/or to use a predicate other than rdfs:member from an application's domain model as the membership predicate. Let's start with a domain resource for a person's net worth, as illustrated below:

# The following is a partial representation of #   http://example.org/netWorth/nw1
# The following is a partial representation of
#   http://example.org/netWorth/nw1
# @base <http://example.org/netWorth/nw1/>

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

      <liabilityContainer/l3>.

From this example, there is a rdf:type of o:NetWorth indicating the resource represents an instance of a person's net worth and o:netWorthOf predicate indicating the associated person. There are two sets of same-subject, same-predicate pairings; one for assets and one for liabilities. It would be helpful to be able to associate these multi-valued sets using a URL for them to assist with managing these, this is done by associating containers with them as illustrated in the 3 examples below:

# The following is an elaborated representation of #   http://example.org/netWorth/nw1/
# The following is an elaborated representation of LDPR
#   http://example.org/netWorth/nw1
# @base <http://example.org/netWorth/nw1/>.

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

<assetContainer/>
   a ldp:Container;

# @base <http://example.org/netWorth/nw1/assetContainer/>
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology/>.
<>
   a ldp:Container, ldp:DirectContainer;

   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject <>;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.

   ldp:containerResource <>;
   ldp:containsRelation o:asset;
   ldp:contains <a1>, <a2>.

# The following is an elaborated representation of LDPC
#   http://example.org/netWorth/nw1/liabilityContainer/

<liabilityContainer/>
   a ldp:Container;

# @base <http://example.org/netWorth/nw1/liabilityContainer/>
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology/>.
<>
   a ldp:Container, ldp:DirectContainer;

   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipSubject <>;
   ldp:membershipPredicate o:liability;
ldp:membershipObject
ldp:MemberSubject.

   ldp:containerResource <>;
   ldp:containsRelation o:liability;
   ldp:contains <l1>, <l2>, <l3>.

The essential structure of the container is the same, but in this example, the consistent membership value (still in the subject position) is not the container itself – it is a separate net worth resource. The membership predicates are o:asset and o:liability – predicates from the domain model. A POST of an asset representation to the asset container will create a new asset and add it to the list of members by adding a new membership triple to the resource and containment triple to the container. You might wonder why http://example.org/netWorth/nw1 isn't made a container itself and POST the new asset directly there. That would be a fine design if http://example.org/netWorth/nw1 had only assets, but if it has separate predicates for assets and liabilities, that design will not work because it is unspecified to which predicate the POST should add a membership triple. Having separate http://example.org/netWorth/nw1/assetContainer/ and http://example.org/netWorth/nw1/liabilityContainer/ container resources allows both assets and liabilities to be created.

# The following is the representation of #   http://example.org/netWorth/nw1/assetContainer/ @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>. <>   a ldp:Container; ldp:membershipSubject <http://example.org/netWorth/nw1>;    ldp:membershipPredicate o:asset; ldp:membershipObject ldp:MemberSubject. <http://example.org/netWorth/nw1>    a o:NetWorth; o:asset <a1>, <a2>.

In this example, clients cannot simply guess which resource This type of container is refered to as an LDP Direct Container . An LDP Basic Container is a constrained form of LDP Direct Container where the membership subject and which predicate is ldp:contains and the container resource is the container itself.

As seen in the assetContainer/ example , clients cannot correctly guess at the membership predicate, triples, so the example includes this information in triples whose subject is the LDPC resource itself.

5.1.1 Container Member Information

In many – perhaps most – applications involving containers, it is desirable Alternatively, servers may provide the net worth resource and supporting containers in a single response representations. When doing this, a preference would be for RDF formats that support multiple named graphs, one named graph for the client net worth resource and then two others for asset and liability containers. This allows for the membership triples to be able to get information about each container member without having represented with the named graph for the net worth resource, while the containment triples would be represented within the liability and asset containers [[rdf11-concepts]]. Generally, the membership triples belong to do the representation of a GET on each one. LDPC allows servers LDP-RR and the containment triples belong to include this information directly in the representation of the container. The server decides LDPC.

Additionally, we could extend our net worth example to include a container for advisors (people) that have managed the amount 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.


# The following is an elaborated representation of
#   http://example.org/netWorth/nw1
# Adding o:advisor but eaving off o:asset and o:liability for brevity.
# @base <http://example.org/netWorth/nw1/>
@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/>.
<>
   a o:NetWorth;
   o:netWorthOf <http://example.org/users/JohnZSmith>;
   o:advisor
         <advisorContainer/bob#me>,
         <advisorContainer/marsha#me>.
         
<advisorContainer/>
   a ldp:Container, ldp:IndirectContainer;
   dcterms:title "The asset advisors of JohnZSmith";
   ldp:containerResource <>;
   ldp:containsRelation o:advisor;
   ldp:insertedContentRelation foaf:primaryTopic;
   ldp:contains
         <advisorContainer/bob>,
         <advisorContainer/marsha>.

To handle this type of data about each member indirection, the triple with predicate of ldp:insertedContentRelation and object of foaf:primaryTopic informs clients that is provided. Some common strategies when POSTing to this container, they need to include providing a fixed number triple of standard properties, or providing the entire RDF representation form (<>, foaf:primaryTopic, topic-URI) to inform the server which URI to use ( topic-URI ) in the new membership triple.

This type of each container is also referred to as an LDP Indirect Container . It is similar to a an LDP Direct Container but it provides an indirection to add (via a create request) as member any resource, or providing nothing. The server application domain and its use-cases will determine how much information such as a URI representing a real-world object, that is required. different from the document that is created.

Continuing on from illustrates the net worth example, 3 types: Basic, Direct and Indirect, along with their relationship to types of LDPRs. It is not expected that there will be additional triples for the member resources (assets) in the representation: a container with a rdf:type solely of ldp:Container .

# The following is the representation of #  http://example.org/netWorth/nw1/assetContainer/ @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>. <> a ldp:Container; dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset; ldp:membershipObject ldp:MemberSubject. <http://example.org/netWorth/nw1>    a o:NetWorth; o:asset <a1>, <a3>, <a2>. <a1>    a o:Stock;    o:value 10000. <a2>    a o:Bond;    o:value 20000. <a3>    a o:RealEstateHolding;    o:value 300000.
Types of Linked Data Platform Containers
Types of Linked Data Platform Containers

In a similar manner, when the representation for PENDING -- table work in progress, if found valuable...we'll keep.

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

Completed Request Effects
Membership Containment
LDPR created in LDPC (any subtype) New triple based on type of asset .../<a1> is returned a server container (see following rows) New triple: (LDPC, ldp:contains, LDPR)
LDPR created in LDP-BC New triple: (LDPC, ldp:contains, LDPR) Same
LDPR created in LDP-DC New triple links LDP-RR to created LDPR. LDP-RR URI may include the membership be same as LDP-DC New triple: (LDPC, ldp:contains, LDPR)
LDPR created in LDP-IC New triple links LDP-RR to content indicated URI New triple: (LDPC, ldp:contains, LDPR)
LDPR is deleted Triples may be removed Triples are removed
LDPC is deleted Triples and member resources may be removed Triples of the form (.../nw1, o:asset, .../a1). 5.1.2 Retrieving Only Non-member Properties (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed

Retrieving Only Empty-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 non-member 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 a LDP-DC. LDP calls these empty-container triples , because they are what remains when the container. 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, it is desired to we define a way to retrieve only the non-member these property values. Defining for each LDPC values (and more generally, a corresponding resource, called way to retrieve only the “ non-member resource ”, whose state is a subset of the state properties used to address other major clusters of use cases). LDP adds parameters to the container, does this. HTTP Prefer header's return=representation preference for this (see for details).

The example listed here only show shows a simple case where only a few simple non-member properties empty-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. [ SPARQL-QUERY ] [[SPARQL-QUERY]]

Here is an example requesting the non-member properties empty-container triples of a container identified by the URL http://example.org/container1/ . In this case, the non-member resource is identified by the URL http://example.org/container1?non-member-properties :

Request:

GET /container1?non-member-properties HTTP/1.1
GET /container1 HTTP/1.1

Host: example.org
Accept:
text/turtle;
charset=UTF-8

Accept: text/turtle; charset=UTF-8
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"

Response:

HTTP/1.1 200 OK
HTTP/1.1 200 OK

Content-Type: text/turtle; charset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325
Link: <http://www.w3.org/ns/ldp/Container>; rel="type"
Preference-Applied: return=representation 

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
<http://example.org/container1/>
   a ldp:Container;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipSubject http://example.org/container1/;
   ldp:membershipPredicate rdfs:member;
   ldp:membershipObject ldp:MemberSubject;
dcterms:publisher
<http://acme.com/>.

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

While the same non-member resource could be used to update the non-member properties via PUT, LDP recommends using PATCH to update these properties, if necessary. It provides no facility for this purpose. updating them via PUT without replacing the entire container's state.

5.1.3

Ordering

There are many cases where an ordering of the members of the container is important. LDPC does not provide any particular support for server ordering of members in containers, because any client can order the members in any way it chooses based on the value of any available property of the members. In the example below, the value of the o:value predicate is present for each member, so the client can easily order the members according to the value of that property. In this way, LDPC avoids the use of RDF constructs like Seq and List for expressing order.

Order becomes more important for LDPC LDP servers when containers are paginated. If the server does not respect ordering when constructing pages, the client would be forced to retrieve all pages before sorting the members, which would defeat the purpose of pagination. In cases where ordering is important, an LDPC server exposes all the members on a page with the proper sort order with relation to all members on the next and previous pages. When the sort is ascending, all the members on a current page have a higher sort order no lower than all members on the previous page and lower sort order no higher than all the members on the next page. page; that is, it proceeds from low to high, but keep in mind that several consecutive pages might have members whose sort criteria are equal. When the sort is descending, the opposite order is used. Since more than one value may be used to sort members, the LDPC specification allows servers to assert the ordered list of sort criteria used to sort the members, using the ldp:containerSortCriteria relation. Each member of the ordered list exposes one ldp:containerSortCriterion , consisting of a ldp:containerSortOrder , ldp:containerSortPredicate , and optionally a ldp:containerSortCollation .

Here is an example container described previously, with representation for ordering of the assets:

# The following is the ordered representation of
# The following is the ordered representation of

#   http://example.org/netWorth/nw1/assetContainer/
# @base <http://example.org/netWorth/nw1/assetContainer/>

@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
<>
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject <http://example.org/netWorth/nw1>;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.

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

<?firstPage>
   a ldp:Page;
   ldp:pageOf <>;
   ldp:containerSortCriteria (#SortValueAscending).

   ldp:pageOf <>;
   ldp:containerSortCriteria (<#SortValueAscending>).

<#SortValueAscending>
   a ldp:ContainerSortCriterion;
   ldp:containerSortOrder ldp:Ascending;

   ldp:containerSortOrder ldp:Ascending;

   ldp:containerSortPredicate o:value.
<http://example.org/netWorth/nw1>
   a o:NetWorth;

   a o:NetWorth;

   o:asset <a1>, <a3>, <a2>.
<a1>
   a o:Stock;
   o:value 100.00.

   a o:Stock;
   o:value 100.00 .

<a2>
   a o:Cash;
   o:value 50.00.

   a o:Cash;
   o:value 50.00 .

<a3>
   a o:RealEstateHolding;
 
 o:value
300000.

   a o:RealEstateHolding;
   o:value 300000 .

As you can see by the addition of the ldp:ContainerSortCriteria predicate, the o:value predicate is used to order the page members in ascending order.  It  It is up to the domain model and server to determine the appropriate predicate to indicate the resource’s order within a page, and up to the client receiving this representation to use that order in whatever way is appropriate, for example to sort the data prior to presentation on a user interface. Also as it is possible for a container to have as its members other containers, the ordering approach doesn't change as containers themselves are LDPRs and the properties from the domain model can be leveraged for the sort criteria.

5.2

General

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

5.2.1 LDPC servers MUST also be conformant LDPR servers. A

Each Linked Data Platform Container MUST also be a conformant conforming Linked Data Platform Resource. 5.2.2 LDPC membership is not exclusive; this means that the same resource ( LDPR or not) which is identified by its canonical URI, MAY be RDF Resource .

The representation of a member LDPC MUST have an rdf:type of more than only one of:

Non-normative note: LDPCs might have additional types , like any RDF resource.

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

LDP Direct Containers and LDP Indirect Containers SHOULD use the ldp:member predicate as an LDPC's membership predicate if there is no obvious predicate from an application vocabulary to use ( LDP-BCs always use ldp:contains ). The state of an LDPC includes information about which resources are its members. In the simplest cases, members, in the form of membership subject will be the LDPC resource itself, but it does not have to be. triples that follow a consistent pattern. The LDPC's state contains enough information for clients to discern the membership predicate is also variable and will often be a predicate from , the server application vocabulary. If there is no obvious predicate from other consistent membership value used in the server application vocabulary to use, LDPC servers SHOULD use container's membership triples ( membership-constant-URI ), and the rdfs:member predicate. position (subject or object) where those URIs occurs in the membership triples . Member resources can be any kind of resource identified by its a URI, LDPR or otherwise. 5.2.4 An LDPC

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

LDP-BCs MUST behave as if their state contains the triple whose subject URI. 5.2.5 An is the LDPC URI, whose predicate is ldp:containerResource , and whose object is the LDPC URI (subject and object are the same URI), but there is no requirement to materialize this triple in LDP-BC representations.

Each LDP Direct Container and LDP Indirect Container representation MUST contain exactly one triple whose subject is the LDPC URI, and whose predicate is either ldp:membershipPredicate ldp:containsRelation or ldp:membershipPredicateInverse ldp:containedByRelation . The object of the triple is constrained by other sections, such as 5.2.5.1 ldp:containsRelation or 5.2.5.2 . 5.2.5.1 For a given ldp:containedByRelation , based on the membership triple pattern used by the container.

LDPCs ( Direct and Indirect Containers only) whose membership triple pattern is T ( membership-constant-URI , membership-predicate , member-derived-URI ) with a MUST contain exactly one triple whose subject C of is the LDPC and URI, whose predicate of is ldp:membershipPredicate ldp:containsRelation , the and whose object MUST be is the URI of the membership predicate P used to indicate membership to membership-predicate .

LDP-BCs MUST behave as if their state contains the triple whose subject is the linked to LDPC , or simply: T = ( C , URI, whose predicate is ldp:membershipPredicate ldp:containsRelation , P) . For the membership predicate URI and whose object used in the is ldp:contains , but there is no requirement to materialize this triple T , it would be found in a resource's same subject R LDP-BC representations.

LDPCs ( Direct and same predicate P Indirect Containers only) whose membership triples of the form: ( R , P , MR ), where MR represents URI of a member resource. 5.2.5.2 For a given triple pattern is T ( member-derived-URI , membership-predicate , membership-constant-URI ) with a MUST contain exactly one triple whose subject C of is the LDPC and URI, whose predicate of is either ldp:membershipPredicateInverse ldp:containedByRelation , the and whose object MUST be is the URI of the membership predicate P used to indicate membership to membership-predicate .

LDP Indirect Containers MUST contain exactly one triple whose subject is the linked to LDPC , or simply: T = ( C , URI, whose predicate is ldp:membershipPredicateInverse ldp:insertedContentRelation , P) . For the membership predicate URI and whose object used in ICR describes how the triple T , it would be found member-derived-URI in a resource's object subject the container's membership triples is chosen. The R member-derived-URI and same predicate is taken from some triple P ( S, P, O ) membership triples of in the form: ( document supplied by the client as input to the create request; if MR , ICR 's value is P , then the R member-derived-URI ), where is MR represents URI of a member resource. 5.2.6 The representation of a LDPC MAY include an arbitrary number of additional triples whose subjects are O . LDP does not define the members of behavior when more than one triple containing the container, or that are from predicate P is present in the representations of client's input. For example, if the members (if they have client POSTs RDF representations). This allows a LDPC server content to provide clients with information about the members without a container that causes the client having container to do create a new LDPR, and that content contains the triple ( <> , foaf:primaryTopic , bob#me ) GET foaf:primaryTopic on each member individually. See sections 5.1.1 Container Member Information , section 4.11 , says that the member-derived-URI is bob#me .

LDP Basic and section 5.10 Direct for additional details. 5.2.7 The representation of a LDPC Containers MUST behave as if they have a ( LDPC URI, rdf:type ldp:insertedContentRelation of ldp:Container , but it MAY have additional , rdf:type ldp:MemberSubject s. 5.2.8 LDPC representations SHOULD NOT use RDF container types rdf:Bag , ) triple, but LDP imposes no requirement to materialize such a triple in representations. The value rdf:Seq ldp:MemberSubject or rdf:List . 5.2.9 LDPC servers SHOULD NOT re-use URIs, regardless of means that the mechanism member-derived-URI is the URI assigned by which members are created ( POST , PUT , etc.). Certain specific cases exist where a LDPC the server MAY delete to a resource and then later re-use the URI when document it identifies creates; for example, if the same resource, but only when consistent with Web architecture [ WEBARCH ]. While it is difficult client POSTs content to provide absolute implementation guarantees of non-reuse in all failure scenarios, re-using URIs creates ambiguities for clients a container that are best avoided. 5.2.10 Some LDPC s have membership objects causes the container to create a new LDPR, ldp:MemberSubject says that are not directly URIs minted upon LDPC member creation, for example URIs with non-empty fragment identifier [ RFC3986 ]. To determine which object the member-derived-URI is the URI assigned to use for the membership triple, LDPC s newly created LDPR.

LDP servers exposing LDPCs MUST contain one triple whose subject is the LDPC URI, predicate is advertise their LDP support by exposing a HTTP ldp:membershipObject , Link header with an object MO . Where MO and the HTTP a target URI R from of POST http://www.w3.org/ns/ldp#Container , and a link relation type of type create (as found (that is, rel='type' ) in all responses to requests made to the LDPC's HTTP response Location Request-URI . LDP servers MAY provide additional HTTP Link: rel='type' header) can be used headers to locate advertise their support for specific LDPC types . The notes on the corresponding LDPR constraint apply equally to LDPCs.

LDP servers SHOULD respect all of a triple client's LDP-defined hints, for example which subsets of LDP-defined state the form: (R, MO, N) and where N can be used client is interested in processing, to construct influence the membership triple set of the form: (membership subject, membership predicate, N) . When ldp:membershipPredicateInverse is used instead triples returned in representations of ldp:membershipPredicate , an LDPC, particularly for large LDPCs. Non-normative note: the membership triple MUST LDPC might be of the form: (N, membership predicate, membership subject) . To indicate paged; paged resources provide no guarantee that the member resource URI is the membership object (the default all triples of a given subset, for example containment triples , are grouped together on one page or typical case), the object MUST be set to predefined URI ldp:MemberSubject such that it forms the triple: ( LDPC URI, ldp:membershipObject , ldp:MemberSubject ) . on a sequence of consecutive pages (see 5.3 ).

HTTP GET 5.3.1

The representation of a LDPC MUST contain a set of membership triples with a consistent subject and predicate whose objects indicate members following one of the container. consistent patterns from that definition. The subject membership-constant-URI of the triples MAY be the container itself or MAY be another resource (as in the example ).  See  See also 5.2.3 . 5.3.2 section on LDPC membership predicates .

LDP servers MAY represent the members of a paged LDPC in a sequential order.  If  If the server does so, it MUST be specify the order using a triple whose subject is the page URI, whose predicate is ldp:containerSortCriteria , and whose object is a rdf:List of ldp:containerSortCriterion resources. The resulting order MUST be as defined by SPARQL SELECT ’s ORDER BY clause [ SPARQL-QUERY ]. [[!SPARQL-QUERY]]. Sorting criteria MUST  be MUST be the same for all pages of a representation; if the criteria were allowed to vary, the ordering among members of a container across pages would be undefined. The first list entry provides the primary sorting criterion, any second entry provides a secondary criterion used to order members considered equal according to the primary criterion, and so on. See section 5.1.4 Ordering for an example. 5.3.3

LDPC page representations ordered using ldp:containerSortCriteria MUST contain, in every ldp:containerSortCriterion list entry, a triple whose subject is the sort criterion identifier, whose predicate is ldp:containerSortPredicate and whose object is the predicate whose value is used to order members between pages (the page-ordering values ). The only predicate literal data types whose behavior LDP constrains are those defined by SPARQL SELECT ’s ORDER BY clause [ SPARQL-QUERY ]. [[!SPARQL-QUERY]]. Other data types can be used, but LDP assigns no meaning to them and interoperability will be limited. 5.3.4

LDPC page representations ordered using ldp:containerSortCriteria MUST contain, in every ldp:containerSortCriterion list entry, a triple whose subject is the sort criterion identifier, whose predicate is ldp:containerSortOrder and whose object describes the order used. LDP defines two values, ldp:Ascending and ldp:Descending , for use as the object of this triple. Other values can be used, but LDP assigns no meaning to them and interoperability will be limited. 5.3.5

LDPC page representations ordered using ldp:containerSortCriteria MAY contain, in any ldp:containerSortCriterion list entry, a triple whose subject is the sort criterion identifier, whose predicate is ldp:containerSortCollation and whose object identifies the collation used. LDP defines no values for use as the object of this triple. While it is better for interoperability to use open standardized values, any value can be used. When the ldp:containerSortCollation triple is absent and the page-ordering values are strings or simple literals [ SPARQL-QUERY ], [[!SPARQL-QUERY]], the resulting order is as defined by SPARQL SELECT’s ORDER BY clause [ SPARQL-QUERY ] [[!SPARQL-QUERY]] using two-argument fn:compare , that is, it behaves as if http://www.w3.org/2005/xpath-functions/collation/codepoint was the specified collation. When the ldp:containerSortCollation triple is present and the page-ordering values are strings or simple literals [ SPARQL-QUERY ], [[!SPARQL-QUERY]], the resulting order is as defined by SPARQL SELECT’s ORDER BY clause [ SPARQL-QUERY ] [[!SPARQL-QUERY]] using three-argument fn:compare , that is, the specified collation. The ldp:containerSortCollation triple SHOULD MUST be omitted for comparisons involving page-ordering values for which [ SPARQL-QUERY ] [[!SPARQL-QUERY]] does not use collations.

5.4

HTTP POST

This specification imposes the following new requirements on Per [HTTP11], this HTTP POST for LDPCs only when an LDPC supports that method. This method is optional and this specification does not impose any new requirement require LDP servers to support that it. When a LDP server chooses to support this method, and [ HTTP11 this specification imposes the following new requirements for LDPCs.

Any server-imposed constraints on creation or update must be advertised ] makes it optional. to clients.

5.4.1

LDPC clients SHOULD create member resources by submitting a representation as the entity body of the HTTP POST to a known LDPC . LDPC. If the resource was created successfully, LDPC 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. 5.4.2 After

When a successful HTTP POST request to a LDPC , results in the new resource creation of an LDPR, the newly created document MUST appear as a member contained resource of the LDPC until the new resource newly created document is deleted or removed by other methods. An

When a successful HTTP POST request to a LDPC MAY also contain resources that were added through other means - for example through results in the user interface creation of an LDPR, the site LDPC MUST update its membership triples to reflect that implements addition, and the LDPC . 5.4.3 LDPC resulting membership triple MUST be consistent with any LDP-defined predicates it exposes. A Direct or Indirect container's membership triples MAY also be modified via through other means.

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

LDP servers MUST that successfully create an LDPR a resource from a RDF representation in the request entity body. body MUST honor the client's requested interaction model(s). The newly created LDPR could also resource can be a thought of as an RDF named graph [[rdf11-concepts]]. If any 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 [[!TURTLE]].

]. 5.4.6 LDPC LDP servers SHOULD use the Content-Type request header to determine the representation format when the request has an entity body. When the header is absent, LDPC servers MAY infer the content type by inspecting the entity body contents [ HTTP11 ]. 5.4.7

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

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

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 LPDRs. 5.4.10 LDPC LDPRs.

LDP servers MAY allow clients to suggest the URI for a resource created through POST , using the HTTP Slug header as defined in [ RFC5023 ]. [[!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. 5.4.11 LDPC

LDP servers that allow member creation via POST SHOULD NOT re-use URIs, per the general requirements on LDPCs . 5.4.12 URIs.

Upon successful creation of a non- RDF and therefore non- LDPR member LDP-BR (HTTP status code of 201-Created and URI indicated by Location response header), LDPC LDP servers MAY create an associated LDPR LDP-RR to contain data about the newly created resource. LDP-BR. If an LDPC server creates this associated LDPR LDP-RR it MUST indicate its location on the HTTP response using the HTTP response header Link and relationship type response header with link relation meta and href to be the URI of the meta-resource [ RFC5988 [[!RFC5988]].

]. 5.4.13 LDPC LDP servers that support POST MUST include an Accept-Post response header on HTTP OPTIONS responses, listing post document 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 an 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. 5.4.14

LDPCs that create new member resources MAY add triples to the container as part of member creation to reflect its factory role. LDP defines the ldp:created ldp:contains predicate for this purpose. An LDPC that tracks members created through the LDPC MUST add a triple to the container whose subject is the container's URI, whose predicate is ldp:created ldp:contains , and whose object is the newly created member resource's URI; it MAY add other triples as well.

5.5 HTTP PUT This specification imposes the following new requirements on HTTP

LDPCs whose PUT ldp:insertedContentRelation for LDPCs only when triple has an LDPC supports object other than ldp:MemberSubject and that method. 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 PUT

Per [HTTP11], this HTTP method is optional and this specification does not impose any new requirement require LDP servers to support that it. When a LDP server chooses to support this method, and [ HTTP11 this specification imposes the following new requirements for LDPCs.

Any server-imposed constraints on creation or update must be advertised ] makes it optional. to clients.

5.5.1 LDPC

LDP servers SHOULD NOT allow HTTP PUT to update a LDPC ’s LDPC’s membership triples ; if the server receives such a request, it SHOULD respond with a 409 (Conflict) status code. 5.5.2 LDPC servers MAY allow updating LDPC non-membership properties using HTTP PUT on a corresponding non-member resource , which MAY exclude server-managed properties such as ldp:membershipSubject , ldp:membershipPredicate and ldp:membershipPredicateInverse . The section 5.9 describes the process by which clients use HTTP OPTIONS to discover whether the server offers such a resource, and if so its URL. 5.5.3 LDPC

LDP servers SHOULD NOT allow HTTP PUT requests with inlined member information in the request representation. See section 5.1.1 Container Member Information for additional details. 5.5.4 LDPC servers that allow member creation via PUT SHOULD NOT re-use URIs, per the general requirements on LDPCs . URIs. For RDF representations (LDP-RRs),the created resource can be thought of as a RDF named graph [[rdf11-concepts]].

5.6

HTTP DELETE

This specification imposes the following new requirements on Per [HTTP11], this HTTP DELETE for LDPRs method is optional and LDPCs only when a LDPC supports that method. This this specification does not impose any new requirement require LDP servers to support that it. When a LDP server chooses to support this method, and [ HTTP11 ] makes it optional. this specification imposes the following new requirements for LDPCs.

5.6.1

When a LDPC member contained resource originally created by the LDPC (for example, one whose representation was HTTP POST ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion (for example, the member is managed by the same server), the LDPC server MUST also remove it from the LDPC by removing the corresponding containment and membership triple. 5.6.2 When the LDPC server successfully completes the DELETE request on a LDPC , it MUST remove any membership triples associated with the LDPC as indicated by the canonical Request-URI . triples.

Non-normative note: The LDPC LDP server MAY might perform additional removal of member resources. actions, as described in the normative references like [[HTTP11]]. For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time. 5.6.3 When the conditions in 5.6.1 hold, and the LDPC tracks member resources that it created using the ldp:created predicate, the LDPC server MUST also remove the deleted member's ldp:created triple. 5.6.4

When a LDPC member contained resource originally created by the LDPC (for example, one whose representation was HTTP POST ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server created an associated LDPR LDP-RR (see 5.4.12 the LDPC POST section ), the LDPC server must MUST also remove the associated LDPR LDP-RR it created.

5.7

HTTP HEAD

Note that certain LDP mechanisms, such as paging, paging , rely on HTTP headers, and HTTP generally requires that HEAD responses include the same headers as GET responses. Also LDPC LDP servers must also include HTTP headers on response to OPTIONS , see . Thus, implementers supporting HEAD should also carefully read the section 5.3 and section 5.9 .

5.8

HTTP PATCH

This specification imposes the following new requirements on Per [HTTP11], this HTTP PATCH for LDPCs only when a LDPC supports that method. This method is optional and this specification does not impose any new requirement require LDP servers to support that it. When a LDP server chooses to support this method, and [ HTTP11 this specification imposes the following new requirements for LDPCs.

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

5.8.1 LDPC

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

5.9

HTTP OPTIONS

This specification imposes the following new requirements on HTTP OPTIONS for LDPCs . LDPCs.

5.9.1 LDPC servers SHOULD define a corresponding non-member resource to support requests for information about a LDPC without retrieving a full representation including all of its members; see section 5.1.2 Retrieving Only Non-member Properties for examples. In responses to OPTIONS requests with an LDPC as the Request-URI , LDPC servers that define a non-member resource SHOULD provide an HTTP Link header whose target URI is the non-member resource , and whose link relation type is http://www.w3.org/ns/ldp#nonMemberResource [ RFC5988 ]. This is the mechanism by which clients discover the URL of the non-member resource. If no such Link header is present, then conservative clients will assume that the LDPC does not have a corresponding non-member resource. For example, if there is a LDPC with URL <containerURL> whose corresponding non-member resource URL is <containerURL>?nonMemberProperties , then the corresponding link header would be Link: <?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#nonMemberResource" 5.9.2

When a LDPC creates a non- LDPR (e.g. binary) LDP-BR member (for example, one whose representation was HTTP POST ed to the LDPC and then referenced by a membership triple) it might create an associated LDPR LDP-RR to contain data about the non- LDPR non-LDPR (see 5.4.12 LDPC POST section ). For non- LDPRs LDP-BRs that have this associated LDPR , LDP-RR, an LDPC server MUST provide an HTTP Link header whose target URI is the associated LDPR , LDP-RR, and whose link relation type is meta [ RFC5988 ]. [[!RFC5988]].

5.10 Member Inlining: Returning All of a Container Page's Members in a Response Feature At Risk

Notable information from normative references

The LDP Working Group proposes incorporation of the features described in this section. The addition While readers, and especially implementers, of resource inlining LDP are assumed to save application latency and server/network load understand the information in controlled environments. Feedback, both positive and negative, is invited by sending email its normative references, the working group has found that certain points are particularly important to understand. For those thoroughly familiar with the mailing list in Status referenced specifications, these points might seem obvious, yet experience has shown that few non-experts find all of This Document . 5.10.1 Introduction them obvious. This section enumerates these topics; it is non-normative. One of simply re-stating (non-normatively) information locatable via the most commonly cited scenarios for resource inlining is to save clients enumerating a container normative references.

Architecture of m members from having to perform m+1 HTTP requests (or m+p , if the container is paged into p pages). The desire World Wide Web

Reference: [[!WEBARCH]]

LDPC membership is to allow the server to reduce the number of HTTP round-trips by returning some (perhaps all) members' content as part of the container's representation. In addition to not exclusive; this means that the general same resource inlining mechanism useful in cases where only (LDPR or not) can be a subset member of the members' content is inlined, more than one LDPC.

LDP also provides a predicate for the special case where all servers should not re-use URIs, regardless of a container's or page's the mechanism by which members are inlined. Rather than forcing the created ( POST , PUT , etc.). Certain specific cases exist where a LDPC server to add might delete a triple for each inlined member, forcing clients to compare the list of inlined members against the set of members in the representation, resource and enlarging then later re-use the representation needlessly, a single triple can be used. This is called member inlining . LDP does not provide clients with any way to detect whether or not URI when it identifies the server is capable of resource inlining (all its resources or any specific resource), nor does same resource, but only when consistent with Web architecture. While it is difficult to provide absolute implementation guarantees of non-reuse in all failure scenarios, re-using URIs creates ambiguities for clients with any way to influence which (if any) resources that are inlined in any given response. The inlining building blocks best avoided.

HTTP 1.1

Reference: [[!HTTP11]]

LDP provides servers can only support representations beyond those necessary to conform to this specification. These could be safely used if certain assumptions hold. This other RDF formats, like N3 or NTriples, but non-RDF formats like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common. HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is no less true for containers than for used to select the format.

LDPRs can be created, updated and deleted using methods not defined in general. See the general cautions on resource inlining . this document, for example through application-specific means, SPARQL UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's normative requirements.

5.10.2 HTTP GET In addition to the requirements set forth in other sections, LDPC servers that support member inlining , and LDP clients aware of servers remove the same facility, must also follow resource identified by the requirements Request-URI in this section. 5.10.2.1 LDPC representations that are member inlined MUST include response to a successful HTTP DELETE request. After such a request, a subsequent HTTP ldp:Page GET resource in on the representation, whether same Request-URI usually results in a 404 (Not found) or not 410 (Gone) status code, although HTTP allows others.

LDP servers can alter the representation contains multiple pages, state of other resources as described in a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 4.11.3.1 . In addition to satisfying those requirements, 9.1). For example, it is acceptable for the representation MUST contain a triple server to remove triples from other resources whose subject or object is the deleted resource as the result of a successful HTTP ldp:Page DELETE resource URI, whose predicate request. It is ldp:membersInlined , also acceptable and whose object is "true"^^xsd:boolean . This is means by which the server communicates common for LDP servers to not do this – the server's behavior can vary, so LDP clients that they cannot depend on it.

LDP servers can avoid implement HTTP GET PATCH requests for the members listed on to allow modifications, especially partial replacement, of their resources. No minimal set of patch document formats is mandated by this document or by the page. 5.10.2.2 LDPC clients SHOULD avoid making HTTP definition of GET PATCH requests against any members in a LDPC representation containing a [[RFC5789]].

When the ldp:Page Content-Type resource with request header is absent from a request, LDP servers might infer the triple described in section 5.10.2.1 , unless there are application-specific reasons for doing so. Clients should note that content type by inspecting the time entity body contents [[HTTP11]].

RDF

Reference: [[RDF-CONCEPTS]]

The state of an LDPR can have triples with any subject(s). The URL used to retrieve the representation is received, of an LDPR need not be the actual state subject of inlined any of its triples.

The representation of an LDPC can include an arbitrary number of additional triples whose subjects are the members may of the container, or that are from the representations of the members (if they have changed due RDF representations). This allows a LDP server to subsequent requests. 5.10.2.3 LDPC provide clients MUST NOT assume that LDPC representations lacking with information about the members without the client having to do a ldp:Page GET resource or lacking the triple described in section 5.10.2.1 on each member individually. See Container Member Information contain all the triples for all members listed in the representation. additional details.

The representation might in fact contain all those triples, or some subset state of them, that might or might not be completely adequate for the client's intended usage, but an LDPR can have more than one triple with a rdf:type predicate.

Feed paging and archiving

Reference: [[RFC5005]]

A LDP client has no way SHOULD NOT present paged resources as coherent or complete, or make assumptions to discern from such a representation which interpretation is accurate. that effect. [[RFC5005]].

6.

HTTP Header Definitions 6.1

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 that would fully include it, see [ RFC5789 ]. based on the Accept-Patch header's design from [[!RFC5789]]. Once LDP is in Candidate Recommendation, 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 modeled modelled after the Accept-Patch header defined in [ RFC5789 ]. [[!RFC5789]].

6.1.1

The syntax for Accept-Post , using the ABNF syntax defined in Section 2.1 of [ HTTP11 ], [[!HTTP11]], is:

Accept-Post = "Accept-Post" ":" 1#media-type

The Accept-Post header specifies a comma-separated list of media- types (with optional parameters) as defined by [ HTTP11 ], [[!HTTP11]], Section 3.7.

6.1.2

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 . 6.1.3

IANA Registration Template

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

Header field name: Accept-Post

Applicable Protocol: HTTP

Author/Change controller: W3C

Specification document: this specification

A. Acknowledgements Preferences on the Prefer Request Header

Summary

Need to update normative reference once RFC number is assigned.
The HTTP Prefer header is queued for an RFC number behind HTTPbis, whose BNF Prefer normatively refers to.

This specification introduces new parameters on the HTTP Prefer request header's return=representation preference [[!Prefer]], 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 [[!Prefer]].

Non-normative note: [[!Prefer]] 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 an 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 [[!Prefer]] 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 [[!Prefer]] 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 an 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 [[!Prefer]] 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. [[!Prefer]] suggests treating similar requests as though none of the conflicting preferences were specified.

This section 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
Empty-container triples http://www.w3.org/ns/ldp#PreferEmptyContainer

Non-normative note: all currently defined URIs are only coherent for LDP-RRs, and in fact only for LDPCs, however in the future it is non-normative. 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/assetContainer/
        
        # @base <http://example.org/netWorth/nw1/assetContainer/>.
        @prefix dcterms: <http://purl.org/dc/terms/>.
        @prefix ldp: <http://www.w3.org/ns/ldp#>.
        @prefix o: <http://example.org/ontology/>.
        <>
           a ldp:Container, ldp:DirectContainer;
           dcterms:title "The assets of JohnZSmith";
           ldp:containerResource <http://example.org/netWorth/nw1>;
           ldp:containsRelation 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#PreferEmptyContainer"

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


        # The following is the ordered representation of
        #   http://example.org/netWorth/nw1/assetContainer/
        
        # @base <http://example.org/netWorth/nw1/assetContainer/>.
        @prefix dcterms: <http://purl.org/dc/terms/>.
        @prefix ldp: <http://www.w3.org/ns/ldp#>.
        @prefix o: <http://example.org/ontology/>.

        <>
           a ldp:Container, ldp:DirectContainer;
           dcterms:title "The assets of JohnZSmith";
           ldp:containerResource <http://example.org/netWorth/nw1>;
           ldp:containsRelation 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 empty-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.


        # The following is the ordered representation of
        #   http://example.org/netWorth/nw1/assetContainer/
        
        # @base <http://example.org/netWorth/nw1/assetContainer/>.
        @prefix dcterms: <http://purl.org/dc/terms/>.
        @prefix ldp: <http://www.w3.org/ns/ldp#>.
        @prefix o: <http://example.org/ontology/>.
        <>
           a ldp:Container, ldp:DirectContainer;
           dcterms:title "The assets of JohnZSmith";
           ldp:containerResource <http://example.org/netWorth/nw1>;
           ldp:containsRelation 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#PreferEmptyContainer"

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 [[HTTPbis]]).


        # The following is the representation of
        #   http://example.org/netWorth/nw1/assetContainer/
        
        # @base <http://example.org/netWorth/nw1/assetContainer/>.
        @prefix dcterms: <http://purl.org/dc/terms/>.
        @prefix ldp: <http://www.w3.org/ns/ldp#>.
        @prefix o: <http://example.org/ontology/>.
        <>
           a ldp:Container, ldp:DirectContainer;
           dcterms:title "The assets of JohnZSmith";
           ldp:containerResource <http://example.org/netWorth/nw1>;
           ldp:containsRelation o:asset;
           ldp:insertedContentRelation ldp:MemberSubject.
        <http://example.org/netWorth/nw1>
           a o:NetWorth;
           o:asset <a1>, <a3>, <a2>.
        

Security Considerations

As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many security-related facilities associated with it and are not required to carry out LDP operations that may be in contradistinction to a particular security policy in place. For example, when faced with an unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization is required. In cases where authentication is provided fails to meet the requirements of a particular access control policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the access control policy.

Acknowledgements

The following people have been instrumental in providing thoughts, feedback, reviews, content, criticism and input in the creation of this specification:

Tim Berners-Lee, Steve Battle, Olivier Berger, Alexandre Bertails, Reza B'Far, Cody Burleson, Richard Cyganiak, Raúl García Castro, Miguel Esteban Gutiérrez, Sandro Hawke, Kingsley Idehen, Yves Lafon, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Antonis Loizou, Ashok Malhota, Roger Menday, Nandana Mihindukulasooriya, Kevin Page, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Andy Seaborne, Steve Speicher, Erik Wilde, Henry Story, Ted Thibodeau, Bart van Leeuwen, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Erik Wilde, David Wood, Martin P. Nally Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon

B. References B.1 Normative references [DC-TERMS] Dublin Core Metadata Initiative. Dublin Core Metadata Initiative Terms, version 1.1. 11 October 2010. DCMI Recommendation. URL: http://dublincore.org/documents/2010/10/11/dcmi-terms/ . [HTML401] Dave Raggett;

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.

Internationalized Resource Identifiers (IRIs) . January 2005. RFC. URL: http://www.ietf.org/rfc/rfc3987.txt Last Call Draft [RFC4627] D. Crockford.
. 15 January 2008. W3C Recommendation. URL: http://www.w3.org/TR/rdf-sparql-query/ [SPARQL-UPDATE] Second Public Working Draft Paul Gearon; Alexandre Passant; Axel Polleres.
Turtle: Terse RDF Triple Language . January 2008. W3C Team Submission. URL: http://www.w3.org/TeamSubmission/turtle/ First Public Working Draft B.2 Informative
Architecture of the World Wide Web, Volume One . 15 December 2004. W3C Recommendation. URL: http://www.w3.org/TR/webarch/ Submission