<!DOCTYPE html>
<html>
<head>
<title>Linked Data Platform 1.0</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "ldp",
// TODO: Confirm short name
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
previousPublishDate: "2013-03-07",
previousMaturity: "FPWD",
previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130307/",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
company: "IBM Corporation", companyURL: "http://ibm.com/" },
{ name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
company: "IBM Corporation", companyURL: "http://ibm.com/" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg: "Linked Data Platform Working Group",
// URI of the public WG page
wgURI: "http://www.w3.org/2012/ldp",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-ldp-wg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa: "1.1",
};
</script>
<style type="text/css">
div.rule {padding-top: 1em;}
div.ldp-issue {
border-color: #E05252;
background: #FBE9E9;
padding: 0.5em;
margin: 1em 0;
position: relative;
clear: both;
border-left-width: .5em;
border-left-style: solid;
}
div.ldp-issue-title {
color: #E05252;
padding-right: 1em;
min-width: 7.5em;
}
</style>
<style type="text/css" media="all">
code {
font-weight:bold;
}
/* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
and is a little hard to read for some folks even on-line. */
</style>
</head>
<body>
<section id='abstract'>
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 <abbr title="Resource Description Framework">RDF</abbr>
data model.
</section>
<section>
<h1 id="intro">Introduction</h1>
<p>This document describes the use
of HTTP for accessing, updating, creating and deleting resources from
servers that expose their resources as Linked Data. It provides some
new rules as well as clarifications and extensions of the four rules
of Linked Data [[LINKED-DATA]]:</p>
<p>1. Use URIs as names for things</p>
<p>2. Use HTTP URIs so that people can look up those
names</p>
<p>3. When someone looks up a URI, provide useful
information, using the standards (RDF*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)</p>
<p>4. Include links to other URIs. so that they can
discover more things</p>
<p>The best practices and
anti-patterns covered in this document are:</p>
<ul>
<li><p>
<em>Resources</em> - a summary of the
HTTP and RDF standard techniques and best practices that you should
use, and anti-patterns you should avoid, when constructing clients
and servers that read and write Linked Data.
</p>
</li>
<li><p>
<em>Containers</em> - defines resources
that allow new resources to be created using HTTP POST and existing
resources to be found using HTTP GET.
</p>
</li>
</ul>
<p>Additionally, it is the intention
of this document to enable additional rules and layered groupings of
rules, such 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.</p>
</section>
<section>
<h1 id="terms">Terminology</h1>
<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
</p>
<dl class="glossary">
<dt>Link</dt>
<dd>A relationship between two resources when one resource (representation) refers to the other resource by means
of a URI [[WEBARCH]].
<p></p></dd>
<dt>Linked Data</dt>
<dd>As defined by Tim Berners-Lee [[LINKED-DATA]].<p></p></dd>
<dt><dfn>Linked Data Platform Resource</dfn> (<dfn><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
<dd>HTTP resource that conforms to the simple lifecycle
patterns and conventions in the <a href="#ldpr">LDPRs</a> section.<p></p></dd>
<dt><dfn>Linked Data Platform Container</dfn> (<dfn><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
<dd>An LDPR representing a collection of same-subject, same-predicate triples, which are uniquely identified by a URI
that responds to client requests for creation, modification, and enumeration of its members.
<p></p></dd>
<dt>Client</dt>
<dd>A program that establishes connections for the purpose of sending requests [[HTTP11]].<p></p></dd>
<dt>Server</dt>
<dd>An application
program that accepts connections in order to service requests by
sending back responses.
<p>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]]. </p></dd>
<dt>Membership triples</dt>
<dd>A set of triples in an LDPC's state that lists its members.
The membership triples of a container all have the same
subject and predicate, and the objects of the membership triples define
the container's members.
<p></p></dd>
<dt>Membership subject</dt>
<dd>The subject of all an LDPC's <a title="Membership triples">membership triples</a>.
<p></p></dd>
<dt>Membership predicate</dt>
<dd>The predicate of all an LDPC's <a title="Membership triples">membership triples</a>.
<p></p></dd>
</dl>
<section>
<h2 id="conventions">Conventions Used in This Document</h2>
<p>Sample resource representations are provided in <code>text/turtle</code>
format [[TURTLE]].</p>
<p>Commonly used namespace prefixes:</p>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
@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#>.</pre>
</section>
</section>
<section id='conformance'>
<p>The status of the sections of Linked Data Platform 1.0 (this document) is as follows:</p>
<ul>
<li>1. Introduction: <b>informative</b></li>
<li>2. Terminology: <b>informative</b></li>
<li>3. Conformance: <b>normative</b></li>
<li>4. Linked Data Platform Resources: <b>normative</b></li>
<li>5. Linked Data Platform Containers: <b>normative</b></li>
<li>A. Acknowledgements: <b>normative</b></li>
<li>B. Change History: <b>normative</b></li>
<li>D.1 Normative references: <b>normative</b></li>
<li>D.2 Informative references: <b>informative</b></li>
</ul>
<p>A conforming <b>LDP Server</b> is an application program that processes HTTP
requests and generates HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
and <a href="#linked-data-platform-containers">LDPCs</a></p>
<p>A conforming <b>LDP Client</b> is an application program that generates HTTP
requests and processes HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
and <a href="#linked-data-platform-containers">LDPCs</a></p>
</section>
<section>
<h1 id="ldpr">Linked Data Platform Resources</h1>
<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) 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. Most LDPRs are domain-specific resources
that contain data for an entity in some domain, which could be
commercial, governmental, scientific, religious, or other.</p>
<p>Some of the rules defined in this document provide
clarification and refinement of the base Linked Data rules [[LINKED-DATA]];
others address additional needs.</p>
<p>The rules for Linked Data Platform Resources address basic
questions such as:</p>
<ul>
<li>What resource formats should be used?</li>
<li>How is optimistic collision detection handled for updates?</li>
<li>What should client expectations be for changes to linked-to resources,
such as type changes?</li>
<li>What can servers do to ease the burden of constraints for resource
creation?</li>
</ul>
<p>Additional informative guidance is available on the <a
href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide"
class="external "
title="Deployment Guide"
rel="nofollow">working group's wiki</a> that addresses deployment
questions such as:</p>
<ul>
<li>What literal value types should be used?</li>
<li>Are there some typical vocabularies that should be reused?</li>
</ul>
<p>The following sections define the rules and
guidelines for use of LDPRs.</p>
<section>
<h2 id="ldpr-general">General</h2>
<div id="ldpr-4_1_1" class="rule">4.1.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
<div id="ldpr-4_1_2" class="rule">4.1.2 LDPR servers MUST provide an RDF representation for LDPRs.
The HTTP Request-URI of the LDPR is typically the subject of most triples in the response.
</div>
<div id="ldpr-4_1_3" class="rule">4.1.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
is common for LDPR servers to need to host binary or text resources
that do not have useful RDF representations.
</div>
<div id="ldpr-4_1_4" class="rule">4.1.4 Clients can access an LDPR using multiple
URLs, for example when DNS aliasing is used. An LDPR server MUST
respond to each of those requests using a single consistent URL, a
canonical URL, for the LDPR which may be found in the response's
Location header and potentially also in the representation of the
LDPR. Clients SHOULD use the canonical URL as an LDPR's identity;
for example, when determining if two URLs refer to the same resource clients
need to compare the canonical URLs not the URLs used to access the resources.
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a></div>
Canonical URL - how to communicate its value to clients
</div>
</div>
<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs 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.
</div>
<div id="ldpr-4_1_5_1" class="rule">4.1.5.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
</div>
<div id="ldpr-4_1_6" class="rule">4.1.6 LDPRs MUST use the predicate <code>rdf:type</code> to
represent the concept of type. The use of non-standard type
predicates, as well as <code>dcterms:type</code>, is
discouraged, as it is not recommended
by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]].
</div>
<div id="ldpr-4_1_7" class="rule">4.1.7 LDPR representations SHOULD have at least one <code>rdf:type</code>
set explicitly. This makes the representations much more useful to
client applications that don’t support inferencing.
</div>
<div id="ldpr-4_1_8" class="rule">4.1.8 Predicate URIs used in LDPR representations SHOULD be HTTP URLs.
These predicate URIs MUST identify LDPRs whose representations are
retrievable. LDPR servers SHOULD provide an RDF Schema [[!RDF-SCHEMA]]
representation of these predicates.
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/9">ISSUE-9</a></div>
Should properties used in LDPR representations be LDPRs?
</div>
</div>
<div id="ldpr-4_1_9" class="rule">4.1.9 LDPRs MUST use at least one RDF triple to represent a link
(relationship) to another resource. In other words, having the source
resource’s URI as the subject and the target resource’s URI as the
object of the triple representing the link (relationship) is enough and
does not require the creation of an intermediate link resource to
describe the relationship.
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/44">ISSUE-44</a></div>
4.1.9. is obscure or too restrictive
</div>
</div>
<div id="ldpr-4_1_10" class="rule">4.1.10 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 be likely be common.
</div>
<div id="ldpr-4_1_11" class="rule">4.1.11 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.
</div>
<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR server responses MUST use entity tags (either weak or strong
ones) as response <code>ETag</code> header values.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/15">ISSUE-15</a></div>
sharing binary resources and metadata
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/16">ISSUE-16</a></div>
Redirection of non-information resources to LDPRs
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/19">ISSUE-19</a></div>
Adressing more error cases
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/33">ISSUE-33</a></div>
Pagination for non-container resources
</div>
<div id="ldpr-4_1_13" class="rule">4.1.13 LDPR
servers SHOULD enable simple creation and modification of LDPRs.
It is
common for LDPR servers to put restrictions on representations – for
example, the range of <code>rdf:type</code> 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.
</div>
</section>
<section>
<h2 id="ldpr-HTTP_GET">HTTP GET</h2>
<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs.
</div>
<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide a <code>text/turtle</code>
representation of the requested LDPR [[!TURTLE]].
</div>
<div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY provide
representations of the requested LDPR beyond those
necessary to conform to this specification, using standard HTTP content negotiation.
If the client does not indicate a preference, <code>text/turtle</code> MUST be returned.
</div>
<div id="ldpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, LDPR
clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
</div>
<div id="ldpr-4_2_5" class="rule">4.2.5 In the absence of special knowledge of the application or domain, LDPR
clients MUST assume that the <code>rdf:type</code> values
of a given LDPR can change over time.
</div>
</section>
<section>
<h2 id="ldpr-HTTP_POST">HTTP POST</h2>
<p>This specification adds no new requirements on HTTP POST for LDPRs.</p>
</section>
<section>
<h2 id="ldpr-HTTP_PUT">HTTP PUT</h2>
<p>This specification imposes the following new requirements on HTTP PUT for LDPRs
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers MUST
replace the entire persistent state of the identified resource with
the entity representation in the body of the request.
LDPR servers MAY ignore server managed properties such as <code>dcterms:modified</code>
and <code>dcterms:creator</code> if they are not under
client control. Any LDPR 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.
</div>
<div id="ldpr-4_4_2" class="rule">4.4.2 LDPR clients SHOULD use the HTTP <code>If-Match</code>
header and HTTP <code>ETags</code> to ensure it isn’t
modifying a resource that has changed since the client last retrieved
its representation. LDPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
to detect collisions. LDPR servers MUST respond with status code 412
(Condition Failed) if <code>ETag</code>s fail to match if there are no other
errors with the request [[!HTTP11]].
</div>
<div id="ldpr-4_4_3" class="rule">4.4.3 LDPR clients SHOULD always assume that the set of predicates for a
resource 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 resource is not limited to any pre-defined
set.
</div>
<div id="ldpr-4_4_4" class="rule">4.4.4 LDPR clients SHOULD assume that an LDPR server could discard triples
whose predicates the server does not recognize or otherwise chooses
not to persist. In other words, LDPR 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 a later HTTP PUT to update the resource.
</div>
<div id="ldpr-4_4_5" class="rule">4.4.5 An LDPR client MUST preserve all triples retrieved 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]].
</div>
<div id="ldpr-4_4_6" class="rule">4.4.6 LDPR servers MAY choose to allow the creation of new resources using HTTP PUT.
</div>
<div id="ldpr-4_4_7" class="rule">4.4.7 LDPR servers SHOULD allow clients to update resources without
requiring detailed knowledge of server-specific constraints.
This is a consequence of the requirement to <a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
</div>
</section>
<section>
<h2 id="ldpr-HTTP_DELETE">HTTP DELETE</h2>
<p>This specification imposes the following new requirements on HTTP DELETE for LDPRs
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpr-4_5_1" class="rule">4.5.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.
</div>
<div id="ldpr-4_5_2" class="rule">4.5.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.
</div>
</section>
<section>
<h2 id="ldpr-HTTP_HEAD">HTTP HEAD</h2>
<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP HEAD method.</div>
<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST indicate their support for HTTP Methods by
responding to a HTTP HEAD request on the LDPR’s URL with the HTTP
Method tokens in the HTTP response header “<code>Allow</code>”.
</div>
</section>
<section>
<h2 id="ldpr-HTTP_PATCH">HTTP PATCH</h2>
<p>This specification imposes the following new requirements on HTTP PATCH for LDPRs
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP PATCH to allow modifications,
especially partial replacement, of their resources [[!RFC5789]]. No
minimal set of patch document formats is mandated by this document.
</div>
<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers SHOULD allow clients to update resources without
requiring detailed knowledge of server-specific constraints.
This is a consequence of the requirement to <a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
</div>
<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH.
<a href="#ldpr-post-1">POST (to an LDPC)</a> and/or <a href="#ldpr-put">PUT</a> should be used as the standard way to create new LDPRs.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/17">ISSUE-17</a></div>
changesets as a recommended PATCH format
</div>
</section>
</section>
<section>
<h1 id="ldpc">Linked Data Platform Containers</h1>
<section class="informative">
<h2 id="ldpc-informative">Informative</h2>
<p>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:</p>
<ol>
<li>To which URLs can I POST to create new resources?</li>
<li>Where can I GET a list of existing resources?</li>
<li>How is the order of the container entries expressed?</li>
<li>How do I get information about the members along with the container?</li>
<li>How do I GET the entries of a large container broken up into pages?</li>
<li>How can I ensure the resource data is easy to query?</li>
</ol>
<p>
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. The membership triples of a container all
have the same subject and predicate – the objects of the membership
triples 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 will be the LDPC resource itself, 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 <code>rdfs:member</code> predicate.
</p>
<p>This document includes a set of guidelines for
using POST to create new resources and add them to the list of
members of a container. This document also explains how to include
information about each member in the container’s own representation
and how to paginate the container representation if it gets too big.</p>
<p>The model for containers follow that of two distinct types: composition and aggregation. Due to composition
constraints, the lifespan of the member resource must match that of its container and it a member resource
can not be a member of more than one container. For both types of containers, members are
only added by using POST, which both creates the resource and inserts a membership triple.
A request to delete a composite container that has members, will result in all
the members and the container itself will be deleted. A member resource is removed
from a composite container by deleting the resource directly, which removes the
membership triple from the container.</p>
<p>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):</p>
<pre class="example"># The following is the representation of
# http://example.org/container1/
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
<>
a ldp:Container;
dcterms:title "A very simple container";
rdfs:member <member1>, <member2>, <member3>.</pre>
<p>This example is very straightforward - the
membership predicate is <code>rdfs:member</code> and the membership subject is the container
itself. 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.</p>
<p>Sometimes it is useful to use a subject
other than the container itself as the membership subject and to use
a predicate other than <code>rdfs:member</code> as the membership predicate. Let's
start with a domain resource for a person's net worth, as illustrated below:</p>
<pre class="example" id="ldpc-ex-membership-full"># The following is a partial representation of
# 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>.
</pre>
<p>From this example, there is a <code>rdf:type</code> of <code>o:NetWorth</code> indicating the
resource represents an instance of a person's net worth and <code>o:netWorthOf</code> 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 below:
</p>
<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
# 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>.
<assetContainer/>
a ldp:Container;
dcterms:title "The assets of JohnZSmith";
ldp:membershipSubject <.>;
ldp:membershipPredicate o:asset.
<liabilityContainer/>
a ldp:Container;
dcterms:title "The liabilities of JohnZSmith";
ldp:membershipSubject <.>;
ldp:membershipPredicate o:liability.
</pre>
<p>The essential structure of the container is
the same, but in this example, the membership subject is not the
container itself – it is a separate net worth resource. The
membership predicates are <code>o:asset</code> and <code>o:liability</code> – 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 container. You might wonder why
<code>http://example.org/netWorth/nw1</code> isn't made a container itself and POST
the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code>
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 <code>http://example.org/netWorth/nw1/assetContainer/</code>
and <code>http://example.org/netWorth/nw1/liabilityContainer/</code> container
resources allows both assets and liabilities to be created.
</p>
<pre class="example" id="ldpc-ex-membership-subj">
# 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.
<http://example.org/netWorth/nw1>
a o:NetWorth;
o:asset <a1>, <a2>.</pre>
<p>In this example, clients cannot simply guess
which resource is the membership subject and which predicate is the
membership predicate, so the example includes this information in
triples whose subject is the LDPC resource itself.
</p>
<div id="ldpc-member_data" class="rule">5.1.1 Container Member Information</div>
<em>This section is non-normative</em>
<p>In many – perhaps most – applications
involving containers, it is desirable for the client to be able to
get information about each container member without having to do a
GET on each one. LDPC allows servers to include this information
directly in the representation of the container. The server decides
the amount of data about each member that is provided. Some common
strategies include providing a fixed number of standard properties,
or providing the entire RDF representation of each member resource,
or providing nothing. The server application domain and its use-cases
will determine how much information is required.</p>
<p>Continuing on from the net worth
example, there will be additional triples for the member resources
(assets) in the representation:</p>
<pre class="example"># 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.
<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.</pre>
<div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
</div>
<em>This section is non-normative</em>
<p>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 properties of
the container. 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 define a way to retrieve only
the non-member property values. Defining for each LDPC a corresponding
resource, called the “non-member resource”, whose state is a subset
of the state of the container, does this.</p>
<p>The example listed here only show
a simple case where only a few simple non-member properties 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]]</p>
<p>
Here is an example requesting the non-member properties of a
container identified by the URL <code>http://example.org/container1/</code>
and adding the query string <code>?non-member-properties</code> :
</p>
<p>Request:</p>
<pre class="example">GET /container1?non-member-properties HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<p>Response:</p>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle; charset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325
@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:membershipPredicate rdfs:member;
dcterms:publisher <http://acme.com/>.</pre>
<div id="ldpc-paging" class="rule">5.1.3 Paging</div>
<em>This section is non-normative</em>
<p>It sometimes happens that a
container is too large to reasonably transmit its representation in a
single HTTP response. This will be especially true if the container
representation includes many triples from the representations of its
members. A client could anticipate that a container 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 container that has been
requested is too big to return in a single message.</p>
<p>
To address this problem, LDPCs should support a technique called Paging. Paging can be achieved with a
simple RDF pattern. For each container resource, <code><containerURL></code>, we define a new
resource <code><containerURL>?firstPage</code>.
The triples in the representation of <code><containerURL>?firstPage</code>
are a subset of the triples in <code><containerURL></code>
- same subject, predicate and object.
</p>
<p>LDPC servers may respond to requests for a
container by redirecting the client to the first page resource –
using a 303 “See Other” redirect to the actual URL for the page
resource.</p>
<p>
Continuing on from the member information from the JohnZSmith net
worth example, we’ll split the response across two pages. The client
requests the first page as <code>http://example.org/netWorth/nw1/assetContainer/?firstPage</code>:
</p>
<pre class="example"># The following is the representation of
# http://example.org/netWorth/nw1/assetContainer/?firstPage
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
<http://example.org/netWorth/nw1/assetContainer/>
a ldp:Container;
dcterms:title "The assets of JohnZSmith";
ldp:membershipSubject <http://example.org/netWorth/nw1>;
ldp:membershipPredicate o:asset.
<http://example.org/netWorth/nw1/assetContainer/?firstPage>
a ldp:Page;
ldp:pageOf <http://example.org/netWorth/nw1/assetContainer/>;
ldp:nextPage <http://example.org/netWorth/nw1/assetContainer/?p=2>.
<http://example.org/netWorth/nw1>
a o:NetWorth;
o:asset
<http://example.org/netWorth/nw1/assetContainer/a1>,
<http://example.org/netWorth/nw1/assetContainer/a4>,
<http://example.org/netWorth/nw1/assetContainer/a3>,
<http://example.org/netWorth/nw1/assetContainer/a2>.
<http://example.org/netWorth/nw1/assetContainer/a1>
a o:Stock;
o:value 100.00.
<http://example.org/netWorth/nw1/assetContainer/a2>
a o:Cash;
o:value 50.00.
# server initially supplied no data for a3 and a4 in this response</pre>
<p>
The following example is the result of retrieving the representation
for the next page:
</p>
<pre class="example"># The following is the representation of
# http://example.org/netWorth/nw1/assetContainer/?p=2
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
<http://example.org/netWorth/nw1/assetContainer/>
a ldp:Container;
dcterms:title "The assets of JohnZSmith";
ldp:membershipSubject <http://example.org/netWorth/nw1>;
ldp:membershipPredicate o:asset.
<http://example.org/netWorth/nw1/assetContainer/?p=2>
a ldp:Page;
ldp:pageOf <http://example.org/netWorth/nw1/assetContainer/>;
ldp:nextPage rdf:nil.
<http://example.org/netWorth/nw1>
a o:NetWorth;
o:asset
<http://example.org/netWorth/nw1/assetContainer/a5>.
<http://example.org/netWorth/nw1/assetContainer/a5>
a o:Stock;
dcterms:title "Big Co.";
o:value 200.02.</pre>
<p>
In this example, there is only one member in the container in the
final page. To indicate this is the last page, a value of <code>rdf:nil</code> is used for the <code>ldp:nextPage</code>
predicate of the page resource.
</p>
<p>LDPC guarantees that any and all the triples
about the members will be on the same page as the membership triple
for the member.</p>
<div id="ldpc-ordering" class="rule">5.1.4 Ordering</div>
<em>This section is non-normative</em>
<p>
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 <code>o:value</code> 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.
</p>
<p>
Order only becomes important for LDPC servers when containers are
paginated. If the server does not respect ordering when constructing
pages, the client is 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 a higher sort order than all members on the
previous page and lower sort order than all the members on the next
page. The LDPC specification provides a predicate - <code>ldp:containerSortPredicates</code>
- that the server may use to communicate to the client which
predicates were used for page ordering. Multiple predicate values may
have been used for sorting, so the value of this predicate is an
ordered list.
</p>
<p>Here is an example container described
previously, with representation for ordering of the assets:</p>
<pre class="example"># The following is the ordered 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.
<?firstPage>
a ldp:Page;
ldp:pageOf <>;
ldp:containerSortPredicates (o:value).
<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.</pre>
<p>
As you can see by the addition of the <code>ldp:containerSortPredicates</code>
predicate, the <code>o:value</code> predicate is used
to define the ordering of the results. 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.
</p>
</section>
<section>
<h2 id="ldpc-general">General</h2>
<p>The Linked Data Platform does not define how clients
discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
Container MUST also be a conformant Linked Data Platform Resource.
</div>
<div id="ldpc-5_2_2" class="rule">5.2.2 For LDPC's of <code>rdf:type</code> of <code>ldp:CompositeContainer</code>,
the same resource which is identified by its canonical URI, MUST be a member of
only a single <code>ldp:CompositeContainer</code>. The same resource can not be a member of multiple Composite LDPCs. The
same resource can be a member of multiple LDPCs of <code>ldp:AggregateContainer</code>.
</div>
<div id="ldpc-5_2_3" class="rule">5.2.3 The state of an LDPC includes information about which
resources are its members. In the simplest cases, the membership subject
will be the LDPC resource itself, but it does not have to be. The
membership predicate is also variable and will often be a predicate
from the server application vocabulary. If there is no obvious
predicate from the server application vocabulary to use, LDPC servers
SHOULD use the <code>rdfs:member</code> predicate.
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/21">ISSUE-21</a></div>
container affordances
</div>
</div>
<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC MUST contain one triple containing the <code>ldp:membershipSubject</code>
predicate when the membership subject is not the LDPC itself.
This triple's object provides clients with the LDPC's membership subject URI.
</div>
<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC MUST contain one triple containing the <code>ldp:membershipPredicate</code>
predicate when
the container predicate is not <code>rdfs:member</code>.
This triple's object provides clients with the LDPC's membership predicate URI.
</div>
<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
additional triples whose subjects are the members of the container,
or that are from the representations of the members (if they have RDF
representations). This allows a LDPC server to provide clients with
information about the members without the client having to do a GET
on each member individually. See section <a href="#ldpc-member_data">5.1.1 Container
Member Information</a> for additional details.
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/13">ISSUE-13</a></div>
Include clarifications about LDPC representations that include member triples
</div>
</div>
<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have <code>rdf:type</code>
of <code>ldp:Container</code>, but it MAY have additional
<code>rdf:type</code>s.
</div>
<div id="ldpc-5_2_8" class="rule">5.2.8 LDPCs SHOULD NOT use RDF container types <code>rdf:Bag</code>,
<code>rdf:Seq</code> or <code>rdf:List</code>.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/38">ISSUE-38</a></div>
filtered representations and inlining
</div>
</section>
<section>
<h2 id="ldpc-HTTP_GET">HTTP GET</h2>
<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of triples with a
consistent subject and predicate whose objects indicate members of
the container. The subject of the triples MAY be the container itself
or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>). See also
<a href="#ldpc-5_2_3">5.2.3</a>.
</div>
<div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers SHOULD support requests for information about a known LDPC
without retrieving a full representation including all of its
members, by the existence of the token "<code>non-member-properties</code>" on the query
component of the LDPC URL. For example, if there is a LDPC URL <code><containerURL>,</code> the URL to request the
non-membership properties would be <code><containerURL>?non-member-properties</code>.
See section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
examples. An LDPC server that does not support a request to
retrieve non-member resource properties via a Request-URI of “<code><containerURL>?non-member-properties</code>”,
MUST return a HTTP status code 404 (Not Found). An LDPC server that supports a request to
retrieve non-member resource properties via a different Request-URI than “<code><containerURL>?non-member-properties</code>”,
MUST return a HTTP Redirection 3xx status code such as 301 (Moved Permanently) or 302 (Found).
</div>
<div id="ldpc-5_3_3" class="rule">5.3.3 An LDPC server that does not support a request to retrieve the first
page resource representation from a known LDPC whose URL is “<code><containerURL></code>” by using
the Request-URI “<code><containerURL>?firstPage</code>”, MUST return a HTTP status code 404 (Not
Found).
An LDPC server that supports that request using a different Request-URI than “<code><containerURL>?firstPage</code>”,
MUST return a HTTP Redirection 3xx status code such as 301 (Moved Permanently) or 302 (Found).
</div>
<div id="ldpc-5_3_4" class="rule">5.3.4 LDPC servers SHOULD support requests for splitting large LDPCs into
pages indicated by a client supplying the token “<code>firstPage</code>”
on the query component of the LDPC URL. For example, if there is a LDPC
URL <code><containerURL></code>, the URL to request
the first page would be <code><containerURL>?firstPage</code>.
The representation for any page, including the first, will include
the URL for the next page. See section <a href="#ldpc-paging">5.1.3 Paging</a> for additional details.
</div>
<div id="ldpc-5_3_5" class="rule">5.3.5 LDPC servers MAY split the response representation of a LDPC regardless
of what the client requested (such as when a client omits a “<code>firstPage</code>”
query component of a request URL). This is also known as
server-initiated paging. See section <a href="#ldpc-paging">5.1.3 Paging</a> for
additional details.
</div>
<div id="ldpc-5_3_5_1" class="rule">5.3.5.1 LDPC servers that initiate paging SHOULD respond to requests for a LDPC
by redirecting the client to the page resource – using a 303 “See
Other” redirect to the actual URL for the page resource.
</div>
<div id="ldpc-5_3_6" class="rule">5.3.6 LDPC servers that support paging MUST include in the page
representation a representation for the LDPC, such that:
</div>
<div id="ldpc-5_3_6_1" class="rule">5.3.6.1 The page resource representation SHOULD have one triple to indicate its
type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
It also SHOULD have 1 triple to indicate the container it is paging,
whose subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
and object is the URL of the LDPC.
</div>
<div id="ldpc-5_3_6_2" class="rule">5.3.6.2 The page resource representation MUST have one triple with the subject
of the page, predicate of <code>ldp:nextPage</code> and
object being the URL for the subsequent page.
</div>
<div id="ldpc-5_3_6_3" class="rule">5.3.6.3 The last page resource representation MUST have one triple with the subject of the
last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/18">ISSUE-18</a></div>
container membership and robust pagination
</div>
<div id="ldpc-5_3_7" class="rule">5.3.7 LDPC servers MAY represent the members of a paged LDPC in a sequential
order. The order MUST be specified using the <code>ldp:containerSortPredicates</code>
predicate whose subject is that of the page and object is a list of
LDPC ordinal predicates. Ordering is only ascending. The only
ordinal predicate literal data types supported are those as defined
by SPARQL SELECT’s ORDER BY clause [[!SPARQL-QUERY]].
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/14">ISSUE-14</a></div>
Include clarifications about ordering in LDPC representations
</div>
</div>
<div id="ldpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>ldp:containerSortPredicates</code>,
the predicate used to indicate ordering, MUST NOT change between
subsequent pages. If it does, ordering among members of a container
across pages is undefined. See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
additional details.
</div>
</section>
<section>
<h2 id="ldpc-HTTP_POST">HTTP POST</h2>
<p>This specification imposes the following new requirements on HTTP POST for LDPCs
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpc-5_4_1" class="rule">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 servers MUST
respond with status code 201 (Created) and the <code>Location</code>
header set to the new resource’s URL.
</div>
<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST
appear as a member of the LDPC until the new resource is deleted or
removed by other methods. An LDPC MAY also contain resources that were
added through other means - for example through the user interface of
the site that implements the LDPC.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/35">ISSUE-35</a></div>
POSTing to a container MUST yield a fresh URI
</div>
<div id="ldpc-5_4_3" class="rule">5.4.3 LDPC servers MAY accept an HTTP POST of non-RDF representations for
creation of any kind of resource, for example binary resources.
</div>
<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
RDF representation in the request entity body. The LDPR could also be a LDPC, therefore servers may
allow the creations of LDPCs within a LDPC.
</div>
<div id="ldpc-5_4_5" class="rule">5.4.5 LDPC servers SHOULD NOT include the representation of the created
resource in the entity body of a 201 (Created) response. In other
words, clients should not expect any representation in the response
entity body on a 201 (Created) response.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/39">ISSUE-39</a></div>
HTTP status codes used for creation
</div>
<div id="ldpc-5_4_6" class="rule">5.4.6 LDPC servers MUST accept a request entity body with a request header
of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
</div>
<div id="ldpc-5_4_7" class="rule">5.4.7 LDPC servers SHOULD use the <code>Content-Type</code> 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]].
</div>
<div id="ldpc-5_4_8" class="rule">5.4.8 In RDF representations, LDPC 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, so
triples whose subject is the null relative URI will usually result in
triples in the created resource whose subject is the created
resource.
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/20">ISSUE-20</a></div>
Identifying and naming POSTed resources
</div>
</div>
<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD assign the subject URI for the resource to be
created using server application specific rules.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/43">ISSUE-43</a></div>
hint at naming a resource on creation
</div>
<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers SHOULD allow clients to create new resources without
requiring detailed knowledge of application-specific constraints.
This is a consequence of the requirement to
<a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
</div>
</section>
<section>
<h2 id="ldpc-HTTP_PUT">HTTP PUT</h2>
<p>This specification imposes the following new requirements on HTTP PUT for LDPCs
only when an LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpc-5_5_1" class="rule">5.5.1 LDPC servers SHOULD NOT allow HTTP PUT to update a LDPC’s members;
if the server receives such a request, it SHOULD respond with a 409
(Conflict) status code.
</div>
<div id="ldpc-5_5_2" class="rule">5.5.2 LDPC servers MAY allow updating LDPC non-membership properties using
HTTP PUT on <code><containerURL>?non-member-properties</code>, which
MAY exclude server-managed properties such as <code>ldp:membershipSubject</code> and <code>ldp:membershipPredicate</code>.
</div>
</section>
<section>
<h2 id="ldpc-HTTP_DELETE">HTTP DELETE</h2>
<p>This specification imposes the following new requirements on HTTP DELETE for LDPRs
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one 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 membership triple.
</div>
<div id="ldpc-5_6_2" class="rule">5.6.2 When the LDPC includes an <code>rdf:type</code> predicate with an object of <code>ldp:AggregateContainer</code>,
the server MAY also delete the resources that are referenced as its contents.
The LDPC membership triple MUST also be updated as defined by <a href="#ldpc-5_6_1">5.6.1</a> above.
</div>
<div id="ldpc-5_6_3" class="rule">5.6.3 When the LDPC includes an <code>rdf:type</code> predicate with an object of <code>ldp:CompositeContainer</code>,
the server MUST also delete the resources that are referenced as its contents.
The LDPC membership triple MUST also be updated as defined by <a href="#ldpc-5_6_1">5.6.1</a> above.
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/28">ISSUE-28</a></div>
transaction/rollback when deleting resources from a LDPC.
note also that 5.6.2's reminder about 5.6.1 is only sensible if there is no transactional behavior in the recursive delete.
in the case where the only observable results are all/nothing, the reminder's effect is unobservable.
</div>
</section>
<section>
<h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
<p>There are no additional requirements on HTTP
HEAD.</p>
</section>
<section>
<h2 id="ldpc-HTTP_PATCH">HTTP PATCH</h2>
<p>This specification imposes the following new requirements on HTTP PATCH for LDPCs
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<div id="ldpc-5_8_1" class="rule">5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred
method for updating LDPC non-membership properties.
</div>
</section>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/7">ISSUE-7</a></div>
What operations are permitted on containers and how do they get invoked?
</div>
</section>
<section class='appendix informative'>
<h2>Acknowledgements</h2>
<p>The following people have been instrumental in providing thoughts, feedback,
reviews, content, criticism and input in the creation of this specification:</p>
<p style="margin-left: 3em;">Arnaud Le Hors, Erik Wilde, Tim Berners-Lee, Steve Battle,
Olivier Berger, Alexandre Bertails, Richard Cyganiak, Raúl García Castro,
Sandro Hawke, Kingsley Idehen, Yves Lafon, Antonis Loizou, Ashok Malhota, Roger Menday,
Nandana Mihindukulasooriya, Kevin Page, Eric Prud'hommeaux, Andy Seaborne,
Henry Story, Ted Thibodeau, Bart van Leeuwen, Ruben Verborgh, David Wood, Martin P. Nally</p>
</section>
<section class='appendix informative' id="history">
<h1>Change History</h1>
<p>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.
</p>
<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">Second Public Working Draft</a></em></blockquote>
<ul>
<li>2013-04-08 - Fixed two old references to BPR (SS)</li>
<li>2013-03-17 - Inserted examples 2&3, a more complete NetWorth resource (SS)</li>
<li>2013-03-15 - Update LDPC glossary term based on Cody's feedback (SS)</li>
<li>2013-03-15 - Additional fix in 5.2.2 for ISSUE-34 (SS)</li>
<li>2013-03-15 - Remove reference to closed issues that don't require edits: ISSUE-27 & ISSUE-45 (SS)</li>
<li>2013-03-14 - General prep for 3rd draft, cleanup and a little restructure (SS)</li>
</ul>
<blockquote><em><a href="http://www.w3.org/TR/2012/WD-ldp-20121025/">First Public Working Draft</a></em></blockquote>
<ul>
<li>2013-03-14 - Fixed up broken fragments and typos before publication (SS)</li>
<li>2013-03-04 - Comments received from David Wood: 5.3.7 & 5.1.3 clarity, other minor edits (part 2) (SS)</li>
<li>2013-03-04 - Comments received from David Wood: abstract, paging informative (part 1) (SS)</li>
<li>2013-03-04 - ISSUE-36 - Added informative text regarding creationg of containers in 5.4.4 (SS)</li>
<li>2013-03-04 - ISSUE-12 - Added section 4.7.3 not to allow PATCH for create (SS)</li>
<li>2013-03-03 - Adjustments to language about different container behavior (SS)</li>
<li>2013-03-02 - Adding trailing '/' on Container URLs to help with readability based on WG suggestion (SS)</li>
<li>2013-02-26 - Updated Acknowledgements section (SS)</li>
<li>2013-02-25 - ISSUE-29 - Use relative URIs in examples (SS)</li>
<li>2013-02-25 - ISSUE-31 - Added a more complete conformance section, motived by SPARQL 1.1 (SS)</li>
<li>2013-02-25 - Updating some simple formatting, reorganizing open issues and todos. (SS) </li>
<li>2013-02-15 - ISSUE-34 - Aggregration: 5.6.1 and 5.6.2 updated for review. (JA) </li>
<li>2013-02-13 - ISSUE-42 - 4.8 Common Properties moved to
<a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates">Deploment Guide</a>
(JA) </li>
<li>2013-02-12 - Fixed up previous publication links (SS) </li>
<li>2013-02-12 - ISSUE-10 - 4.1.12 to be MUST use entity tags (either weak or strong ones) (SS) </li>
<li>2013-02-12 - ISSUE-11 - 4.4.1 Relaxed the MUST ignore dc:modified/creator to MAY (SS) </li>
<li>2013-01-16 - ISSUE-25 Updated introduction. 5.2.2 changed to MUST NOT be in multiple containers. Flipped 5.6.1/2 as
first rule leads to 2nd. 5.6.2(was .1) Delete LDPC MUST also delete members. (SS)</li>
<li>2013-01-16 - Added new issues ranging from 26-43. Removed closed/deferred issues: 2 & 3 (SS)</li>
<li>2012-12-28 - Fixed Typos. Separated some compound rules like 4.1.5. Rewording for clarity: 4.1.10,
Text being repeated in several places centralized and cross-linked. Made printed code output easier to read
on black & white printers. Exposed terms defined in-line under LDPC as Terminology (tentatively). Removed non-normative
qualifer from section 5.2. Added "several" editors' to-dos.(JA)</li>
<li>2012-11-05 - minor rewording from ISSUE-24</li>
<li>2012-11-03 - ISSUE-22, ISSUE-23: changed sections 4.2.3 and 5.4.7. Removed closed issues. (SS)</li>
<li>2012-11-03 - ISSUE-24 Delete the phrase in 4.5.1 that nays "until ...Request URI"
and adding a sentence, "Clients should note that servers may reuse a Request-URI under some circumstances."</li>
<li>2012-11-03 - ISSUE-6 Removed section 4.1.9. Shifted up sections .10 through .13.</li>
<li>2012-11-01 - Fixed minor typo and added some notes (SS)</li>
</ul>
<blockquote><em><a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">Submission</a></em></blockquote>
<ul>
<li>2012-10-15 - ISSUE-8 Changed references from LDBP to LDP, removed definition for "profile" and new namespace (SS)</li>
<li>2012-10-15 - Included additional open ISSUES from Oct 15 WG meeting: 22, 23, 24 (SS)</li>
<li>2012-10-14 - Added open ISSUES and formating to prep for public working draft (SS)</li>
<li>2012-09-20 - Sent pull request re LINKED-DATA and added suggestion for <code>ldp</code> namespace (SS)</li>
<li>2012-09-19 - Repairing references and forward reference to biblio.js updates (SS)</li>
<li>2012-09-19 - Fixed rdfs:label range to be rdfs:Literal (SS)</li>
<li>2012-09-19 - ISSUE-1 Define Turtle as the required serialization format for LDP (SS)</li>
<li>2012-09-18 - Initial ReSpec'ing of <a href="http://www.w3.org/Submission/ldbp/">Member Submission - Linked Data Basic Profile 1.0</a> (SS)</li>
<li>2012-09-18 - Fixed up some links and worked on references, work left to do. (SS)</li>
</ul>
</section>
<section class='appendix informative' id="todos">
<h1>Editor Todos and Notes</h1>
<p>Other than LDP <a href="http://www.w3.org/2012/ldp/track/actions">open actions</a> and <a href="http://www.w3.org/2012/ldp/track/issues">issues</a>, included here are transient tasks and notes
editors use. They have not meaning in final product of a published working draft and will be removed prior to publishing.</p>
<ul>
<li>Insert some additional examples</li>
<li>4.1.2: "the" subject ?= Request-URI ... not always (hash URIs)
</li>
<li>4.1.5: refers to RDF *Primer* - is that intentful?
</li>
<li>4.1.6.1: why does it have the extra .1, to avoid renumbering? should we divide General into subsections
for vocab/client/server constraints? Do we need to define "LDPR server"? ...think about role vs artifact. If
"an LDPR server" hosts both LDPRs and non-LDPR HTTP resources, 4.1.2 (if "the code" == LDPR server) could be
read to say that in order to conform to spec it must serve up RDF for non-LDPRs. Hits 5.2.1 too.
</li>
<li>4.1.7: define "explicitly"?
</li>
<li>4.4.1: specifically calls out 2 props; issue-11 note talks about "server-managed props" which is not defined.
</li>
<li>4.4.4/4.4.5 could be read to overlap/dup one another
</li>
<li>Deployment guide (was: 4.8 Common Properties) talks about rdfs:Range which implies inferencing.
4.1.7 spec says want to avoid putting that reqt on clients.
</li>
<li>5.2.1: 4.1.6.1 issue linked to this text
</li>
<li>5.2.2: I think we mean "resource" == any HTTP resource, not just LDPR. If so, perhaps we should be more explicit.
5.2.1 might be the place.
</li>
<li>5.2.3-5.2.5: don't we need to tell clients to fetch LDPC's non-member properties, introspect for these predicates,
and (if either not found) supply the defaults? that is the net effect of what's here.
</li>
<li>5.4.5: in light of the existence of server-managed properties, why not allow response body from create?
</li>
<li>Per David Wood, 'Sections 4.4.1, 4.5.1, 4.7.1, 5.4.1, 5.6.1 and 5.8.1 all relate to
allowable write operations. I suggest adding the statement, "An LDPR server
MAY require a user to be authenticated and authorized before this action is
permitted." to each of those sections.', consider place to edit this in.</li>
</ul>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/37">ISSUE-37</a></div>
Additional introductory text on the LDP data and interaction model
</div>
<div class="ldp-issue">
<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/5">ISSUE-5</a></div>
Add a section explaining how LDP is related to Graph Store Protocol
</div>
</section>
</body>
</html>