--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp.html Tue Sep 18 13:35:33 2012 -0400
@@ -0,0 +1,1359 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>Linked Data Basic Profile 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='http://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: "ldbp",
+ // 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: "2012-03-26",
+ previousMaturity: "SUBM",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "https://dvcs.w3.org/hg/ldpwg/ldbp.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/" },
+ ],
+
+ // 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",
+ };
+ </script>
+ <style type="text/css">
+ div.rule {padding-top: 1em;}
+ </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 RDF.
+</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 [4Rules]</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*, SPARQL)</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 profiles. The scope is intentionally
+ narrow to provide a set of key rules for reading and writing Linked
+ Data that most, if not all, other profiles will depend on 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 [RFC2616]
+</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]</dd>
+
+ <dt>Linked Data</dt>
+ <dd>As defined by Tim Berners-Lee. [4Rules]</dd>
+
+ <dt>Profile</dt>
+ <dd>A specification that defines the needed components from other specifications as
+ well as providing additional clarifications as needed.</dd>
+
+ <dt>Basic Profile Resource (BPR)</dt>
+ <dd>HTTP resource that conforms to the simple lifecycle
+ patterns and conventions in this document.</dd>
+
+ <dt>Basic Profile Container (BPC)</dt>
+ <dd>BPR resource that also conforms to additional patterns and conventions in this
+ document for managing membership.</dd>
+
+ <dt>Client</dt>
+ <dd>A program that establishes connections for the purpose of sending requests. [RFC2616]</dd>
+
+ <dt>Server</dt>
+ <dd>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.
+ [RFC2616]</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 bp: <http://open-services.net/ns/basicProfile#>.
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.</pre>
+</section>
+</section>
+
+<section id='conformance'></section>
+
+<section>
+<h1 id="bpr">Basic Profile Resource</h1>
+ <p>Basic Profile Resources (BPRs) are HTTP resources
+ that conform to the simple patterns and conventions in this section.
+ HTTP requests to access, modify, create or delete BPRs are accepted
+ and processed by BPR servers. Most BPRs 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 [4Rules],
+ others address additional needs.</p>
+ <p>The rules for Basic Profile Resources address basic
+ questions such as:</p>
+ <ul>
+ <li>What resource formats should be used?</li>
+ <li>What literal value types should be used?</li>
+ <li>Are there some typical vocabularies that should be reused?</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>The following sections define the rules and
+ guidelines for use of BPRs.</p>
+
+<section>
+<h2 id="bpr-general">General</h2>
+
+ <div id="bpr-4_1_1" class="rule">4.1.1 BPR servers MUST at least be HTTP/1.1 conformant servers [RFC2616].</div>
+ <div id="bpr-4_1_2" class="rule">4.1.2 BPR servers MUST provide an RDF representation for BPRs. The subject
+ is typically the BPR itself.
+ </div>
+ <div id="bpr-4_1_3" class="rule">4.1.3 BPR servers MAY host a mixture of BPRs and non-BPRs. For example, it
+ is common for BPR servers to need to host binary or text resources
+ that do not have useful RDF representations.
+ </div>
+ <div id="bpr-4_1_4" class="rule">4.1.4 Clients can access a BPR using multiple
+ URLs, for example when DNS aliasing is used. A BPR server MUST
+ respond to each of those requests using a single consistent URL, a
+ canonical URL, for the BPR which may be found in the response's
+ Location header and potentially also in the representation of the
+ BPR. Clients SHOULD use that canonical URL to identify the BPR.
+ </div>
+ <div id="bpr-4_1_5" class="rule">4.1.5 BPR predicates SHOULD use standard vocabularies such as Dublin Core
+ [Dublin Core], RDF [RDF] and RDF Schema [RDF Schema], whenever
+ possible. BPRs SHOULD reuse existing vocabularies instead of creating
+ their own duplicate vocabulary terms.
+ </div>
+ <div id="bpr-4_1_6" class="rule">4.1.6 BPR predicates MUST use well-known RDF vocabularies as defined in
+ section <a href="#bpr-prop">4.8 Common Properties</a> wherever a predicate’s meaning matches
+ one of them.
+ </div>
+ <div id="bpr-4_1_6_1" class="rule">4.1.6.1 BPRs 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. [DC-RDF]
+ </div>
+ <div id="bpr-4_1_7" class="rule">4.1.7 BPR 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="bpr-4_1_8" class="rule">4.1.8 Predicate URIs used in BPR representations SHOULD be HTTP URLs.
+ These predicate URIs MUST identify BPRs whose representations are
+ retrievable. BPR servers SHOULD provide an RDF Schema [RDF Schema]
+ representation of these predicates.
+ </div>
+ <div id="bpr-4_1_9" class="rule">4.1.9 BPR representations MUST use only the following standard datatypes.
+ RDF does not by itself define datatypes to be used for literal
+ property values, therefore a set of standard datatypes based on [XSD
+ Datatypes] and [RDF] are to be used: </div>
+ <table border="1" cellspacing="5" summary="Datatype to use with RDF literals">
+ <thead>
+ <tr><th>URI</th><th>Description</th></tr>
+ </thead>
+ <tbody>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#boolean</code></td><td>Boolean type as specified by XSD Boolean</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#date</code></td><td>Date type as specified by XSD date</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#dateTime</code></td><td>Date and Time type as specified
+ by XSD dateTime</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#decimal</code></td><td>Decimal number type as specified
+ by XSD Decimal</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#double</code></td><td>Double floating-point number type as
+ specified by XSD Double</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#float</code></td><td>Floating-point number type as
+ specified by XSD Float</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#integer</code></td><td>Integer number type as specified by
+ XSD Integer</td></tr>
+ <tr><td><code>http://www.w3.org/2001/XMLSchema#string</code></td><td>String type as specified by XSD String</td></tr>
+ <tr><td><code>http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</code></td><td>Literal XML value as specified by RDF</td></tr>
+ </tbody>
+ </table>
+
+ </div>
+ <div id="bpr-4_1_10" class="rule">4.1.10 BPRs 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 represent the link (relationship) is enough and
+ does not require the creation of an intermediate link resource to
+ describe the relationship.
+ </div>
+ <div id="bpr-4_1_11" class="rule">4.1.11 BPR servers MAY support additional standard representations. These
+ could be other RDF formats, like N3 or NTriples, but non-RDF formats
+ like HTML and JSON would be likely be common.
+ </div>
+ <div id="bpr-4_1_12" class="rule">4.1.12 BPRs MAY be created, updated and deleted using methods not defined in
+ this document, for example through application-specific means, SPARQL
+ UPDATE, etc. [SPARQL-UPDATE]
+ </div>
+ <div id="bpr-4_1_13" class="rule">4.1.13 BPR server responses MUST contain accurate response <code>ETag</code>
+ header values.
+ </div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_GET">HTTP GET</h2>
+ <div id="bpr-4_2_1" class="rule">4.2.1 BPR servers MUST support the HTTP GET Method for BPRs.
+ </div>
+ <div id="bpr-4_2_2" class="rule">4.2.2 BPR servers MUST provide an <code>application/rdf+xml</code>
+ representation of the requested BPR.
+ </div>
+ <div id="bpr-4_2_3" class="rule">4.2.3 BPR servers SHOULD provide a <code>text/turtle</code>
+ representation of the requested BPR.
+ </div>
+ <div id="bpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, BPR
+ clients MUST assume that any BPR may have multiple values for <code>rdf:type</code>.
+ </div>
+ <div id="bpr-4_2_5" class="rule">4.2.5 In the absence of special knowledge of the application or domain, BPR
+ clients MUST assume that the <code>rdf:type</code> values
+ of a given BPR may change over time.
+ </div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_POST">HTTP POST</h2>
+ <p>There are no additional requirements on HTTP POST for BPRs.</p>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_PUT">HTTP PUT</h2>
+
+ <div id="bpr-4_4_1" class="rule">4.4.1 If HTTP PUT is performed on an existing resource, BPR servers MUST
+ replace the entire persistent state of the identified resource with
+ the entity representation in the body of the request. The only
+ recognized exception are the properties <code>dcterms:modified</code>
+ and <code>dcterms:creator</code> that are never under
+ client control - BPR servers MUST ignore any values of these
+ properties that are provided by the client. Any BPR 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="bpr-4_4_2" class="rule">4.4.2 BPR 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. BPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
+ to detect collisions. BPR 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. [RFC2616]
+ </div>
+ <div id="bpr-4_4_3" class="rule">4.4.3 BPR 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 its triples, and the set of predicates that
+ are used in the state of a resource is not limited to any pre-defined
+ set.
+ </div>
+ <div id="bpr-4_4_4" class="rule">4.4.4 BPR clients SHOULD assume that a BPR server could discard triples
+ whose predicates the server does not recognize or otherwise chooses
+ not to persist. In other words, BPR servers MAY restrict themselves
+ to a known set of predicates, but BPR 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="bpr-4_4_5" class="rule">4.4.5 A BPR 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="bpr-4_4_6" class="rule">4.4.6 BPR servers MAY choose to allow the creation of new resources using HTTP PUT.
+ </div>
+ <div id="bpr-4_4_7" class="rule">4.4.7 BPR servers SHOULD allow clients to update resources without
+ requiring detailed knowledge of server-specific constraints. It is
+ common for BPR servers to put restrictions on representations – for
+ example, the range of <code>rdf:type</code>, datatypes of
+ predicates and number of occurrences of predicates in triples, but
+ servers SHOULD minimize those restrictions. In other words, BPR
+ servers need to enable simple modification of BPRs. Enforcement of
+ more complex constraints will greatly restrict the types of clients
+ that can modify resources. For some server applications, excessive
+ constraints on modification of resources may be required.
+ </div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_DELETE">HTTP DELETE</h2>
+ <div id="bpr-4_5_1" class="rule">4.5.1 BPR 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, until another resource is created or associated with the same
+ Request-URI.
+ </div>
+ <div id="bpr-4_5_2" class="rule">4.5.2 BPR 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 BPR servers to
+ not do this – behavior is server application specific.
+ </div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_HEAD">HTTP HEAD</h2>
+ <div id="bpr-4_6_1" class="rule">4.6.1 BPR servers MUST support the HTTP HEAD method.</div>
+ <div id="bpr-4_6_2" class="rule">4.6.2 BPR servers MUST indicate their support for HTTP Methods by
+ responding to a HTTP HEAD request on the BPR’s URL with the HTTP
+ Method tokens in the HTTP response header “<code>Allow</code>”.
+ </div>
+</section>
+
+<section>
+<h2 id="bpr-HTTP_PATCH">HTTP PATCH</h2>
+ <div id="bpr-4_7_1" class="rule">4.7.1 BPR 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="bpr-4_7_2" class="rule">4.7.2 BPR servers SHOULD allow clients to update resources without
+ requiring detailed knowledge of server-specific constraints. It is
+ common for BPR servers to put restrictions on representations – for
+ example, the range of <code>rdf:type</code>, datatypes of
+ predicates and number of occurrences of predicates in triples – but
+ server enforcement of detailed, domain-specific constraints will
+ greatly restrict the types of clients who can update resources.
+ </div>
+</section>
+
+<section>
+<h2 id="bpr-prop">Common Properties</h2>
+ <p>
+ This section summarizes some well-known RDF vocabularies that MUST be
+ used in Basic Profile Resources wherever a resource needs to use a
+ predicate whose meaning matches one of these. For example, if a BP
+ resource has a <em>description</em>, and the application semantic of that
+ <em>description</em> is compatible with <code>dcterms:description</code>,
+ then <code>dcterms:description</code> MUST be used. If
+ needed, additional application-specific predicates MAY be used. A
+ specification for a domain that is based on BP may require one or
+ more of these properties for a particular resource type. The Range
+ column in the tables below identify the RECOMMENDED <code>rdfs:range</code>
+ for the properties.
+ </p>
+ <div id="bpr-4_8_1" class="rule">4.8.1 From Dublin Core</div>
+ <p>
+ URI: <code>http://purl.org/dc/terms/</code>
+ </p>
+ <table border="1" cellspacing="5" summary="Dublin Core properties recommended">
+ <tr>
+ <td>Property</td>
+ <td>Range</td>
+ <td>Comment</td>
+ </tr>
+ <tr>
+ <td><code>dcterms:contributor</code></td>
+ <td><code>dcterms:Agent</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>dcterms:creator</code></td>
+ <td><code>dcterms:Agent</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>dcterms:created</code></td>
+ <td><code>xsd:dateTime</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>dcterms:description</code></td>
+ <td><code>rdf:XMLLiteral</code></td>
+ <td>
+ Descriptive text about the resource represented as rich text in
+ XHTML format. SHOULD include only content that is valid and suitable inside an XHTML
+ <code><div></code> element.
+ </td>
+ </tr>
+ <tr>
+ <td><code>dcterms:identifier</code></td>
+ <td><code>rdfs:Literal</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>dcterms:modified</code></td>
+ <td><code>xsd:dateTime</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>dcterms:relation</code></td>
+ <td><code>rdfs:Resource</code></td>
+ <td>The HTTP URI of a related resource. This is the
+ predicate to use when you don't know what else to use. If you know
+ more specifically what sort of relationship it is, use a more
+ specific predicate.</td>
+ </tr>
+ <tr>
+ <td><code>dcterms:subject</code></td>
+ <td><code>rdfs:Resource</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>dcterms:title</code></td>
+ <td><code>rdf:XMLLiteral</code></td>
+ <td>A name given to the resource. Represented as rich text in XHTML
+ format. SHOULD include only content that is valid inside an XHTML <code><span></code>
+ element.</td>
+ </tr>
+ </table>
+
+ <p>
+ The predicate <code>dcterms:type</code> SHOULD NOT be
+ used, instead use <code>rdf:type</code>. [DC-RDF].
+ </p>
+
+ <div id="bpr-4_8_2" class="rule">4.8.2 From RDF</div>
+ <p>
+ URI: <code>http://www.w3.org/1999/02/22-rdf-syntax-ns#</code>
+ </p>
+ <table border="1" cellspacing="5" summary="RDF properties recommended">
+ <tr>
+ <td>Property</td>
+ <td>Range</td>
+ <td>Comment</td>
+ </tr>
+ <tr>
+ <td><code>rdf:type</code></td>
+ <td><code>rdfs:Class</code></td>
+ <td>The type or types of the resource</td>
+ </tr>
+ </table>
+
+ <div id="bpr-4_8_3" class="rule">4.8.3 From RDF Schema</div>
+ <p>
+ URI: <code>http://www.w3.org/2000/01/rdf-schema#</code>
+ </p>
+
+
+ <table border="1" cellspacing="5" summary="RDF Schema properties recommended">
+ <tr>
+ <td>Property</td>
+ <td>Range</td>
+ <td>Comment</td>
+ </tr>
+ <tr>
+ <td><code>rdfs:member</code></td>
+ <td><code>rdfs:Resource</code></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td><code>rdfs:label</code></td>
+ <td><code>rdfs:Resource</code></td>
+ <td>Only use this in vocabulary documents, to define
+ the name of the vocabulary term.</td>
+ </tr>
+ </table>
+</section>
+</section>
+
+<section>
+<h1 id="bpc">Basic Profile Container</h1>
+
+<section class="informative">
+<h2 id="bpc-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 BPC 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 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 bp: <http://open-services.net/ns/basicProfile#>.
+
+<http://example.org/container1>
+ a bp:Container;
+ dcterms:title "A very simple container";
+ rdfs:member
+ <http://example.org/container1/member1>,
+ <http://example.org/container1/member2>,
+ <http://example.org/container1/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, as illustrated
+ below.</p>
+
+<pre class="example">
+# The following is the representation of
+# http://example.org/netWorth/nw1/assetContainer
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix bp: <http://open-services.net/ns/basicProfile#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/netWorth/nw1/assetContainer>
+ a bp:Container;
+ bp:membershipSubject <http://example.org/netWorth/nw1>;
+ bp:membershipPredicate o:asset.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset
+ <http://example.org/netWorth/nw1/assetContainer/a1>,
+ <http://example.org/netWorth/nw1/assetContainer/a2>.</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 predicate is <code>o:asset</code> – a predicate from the domain model. A POST to
+ this 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 we didn’t just make <code>http://example.org/netWorth/nw1</code> a container 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>
+ <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 BPC resource itself.
+ </p>
+
+ <div id="bpc-member_data" class="rule">5.1.1 Container Member Information</div>
+ <em>This section is informative</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. BPC 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 rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix bp: <http://open-services.net/ns/basicProfile#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/netWorth/nw1/assetContainer>
+ a bp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ bp:membershipSubject <http://example.org/netWorth/nw1>;
+ bp:membershipPredicate o:asset.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset
+ <http://example.org/netWorth/nw1/assetContainer/a1>,
+ <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 10000.
+<http://example.org/netWorth/nw1/assetContainer/a2>
+ a o:Bond;
+ o:value 20000.
+<http://example.org/netWorth/nw1/assetContainer/a3>
+ a o:RealEstateHolding;
+ o:value 300000.</pre>
+
+ <div id="bpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
+ </div>
+ <em>This section is informative</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 BPC 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.</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; chartset=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 bp: <http://open-services.net/ns/basicProfile#>.
+
+<http://example.org/container1>
+ a bp:Container;
+ dcterms:title "A Basic Profile Container of Acme Resources";
+ bp:membershipPredicate rdfs:member;
+ dcterms:publisher <http://acme.com/>.</pre>
+
+ <div id="bpc-paging" class="rule">5.1.3 Paging</div>
+ <em>This section is informative</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 may 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 may recognize that a container that has been
+ requested is too big to return in a single message.</p>
+ <p>
+ To address this problem, BPCs may 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>BPC 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 bp: <http://open-services.net/ns/basicProfile#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/netWorth/nw1/assetContainer>
+ a bp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ bp:membershipSubject <http://example.org/netWorth/nw1>;
+ bp:membershipPredicate o:asset.
+
+<http://example.org/netWorth/nw1/assetContainer?firstPage>
+ a bp:Page;
+ bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
+ bp: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 bp: <http://open-services.net/ns/basicProfile#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/netWorth/nw1/assetContainer>
+ a bp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ bp:membershipSubject <http://example.org/netWorth/nw1>;
+ bp:membershipPredicate o:asset.
+
+<http://example.org/netWorth/nw1/assetContainer?p=2>
+ a bp:Page;
+ bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
+ bp: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>bp:nextPage</code>
+ predicate of the page resource.
+ </p>
+ <p>BPC 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="bpc-ordering" class="rule">5.1.4 Ordering</div>
+ <em>This section is informative</em>
+ <p>
+ There are many cases where an ordering of the members of the
+ container is important. BPC 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, BPC avoids the use of RDF
+ constructs like Seq and List for expressing order.
+ </p>
+ <p>
+ Order only becomes important for BPC 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, a BPC 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 BPC specification provides a predicate - <code>bp: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 rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix bp: <http://open-services.net/ns/basicProfile#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/netWorth/nw1/assetContainer>
+ a bp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ bp:membershipSubject <http://example.org/netWorth/nw1>;
+ bp:membershipPredicate o:asset.
+
+<http://example.org/netWorth/nw1/assetContainer?firstPage>
+ a bp:Page;
+ bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
+ bp:containerSortPredicates (o:value).
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset
+ <http://example.org/netWorth/nw1/assetContainer/a1>,
+ <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.
+<http://example.org/netWorth/nw1/assetContainer/a3>
+ a o:RealEstateHolding;
+ o:value 300000.</pre></div>
+ <p>
+ As you can see by the addition of the <code>bp: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 class="informative">
+<h2 id="bpc-general">General</h2>
+ <div id="bpc-5_2_1" class="rule">5.2.1 BPC servers MUST also be conformant BPR servers. A Basic Profile
+ Container is a resource that is a Basic Profile Resource.
+ </div>
+ <div id="bpc-5_2_2" class="rule">5.2.2 The same resource MAY be a member of multiple BPCs. This happens
+ commonly if one container is a view onto a larger container.
+ </div>
+ <div id="bpc-5_2_3" class="rule">5.2.3 The representation of a BPC includes information about which
+ resources are its members. The set of members of a container is 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 BPC 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, BPC servers
+ SHOULD use the <code>rdfs:member</code> predicate.
+ </div>
+ <div id="bpc-5_2_4" class="rule">5.2.4 A BPC MUST contain one triple for the <code>bp:membershipSubject</code>
+ predicate that indicates the subject of the membership triples when container subject is not the BPC itself.
+ </div>
+ <div id="bpc-5_2_5" class="rule">5.2.5 A BPC MUST contain one triple for the <code>bp:membershipPredicate</code>
+ predicate that indicates the predicate of the membership triple when
+ the container predicate is not <code>rdfs:member</code>.
+ </div>
+ <div id="bpc-5_2_6" class="rule">5.2.6 The representation of a BPC 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 BPC 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="#bpc-member_data">5.1.1 Container
+ Member Information</a> for additional details.
+ </div>
+ <div id="bpc-5_2_7" class="rule">5.2.7 The representation of a BPC MUST have <code>rdf:type</code>
+ of <code>bp:Container</code>, but it MAY have additional
+ <code>rdf:type</code>s.
+ </div>
+ <div id="bpc-5_2_8" class="rule">5.2.8 BPCs SHOULD NOT use RDF container types <code>rdf:Bag</code>,
+ <code>rdf:Seq</code> and <code>rdf:List</code>.
+ </div>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_GET">HTTP GET</h2>
+ <div id="bpc-5_3_1" class="rule">5.3.1 The representation of a BPC 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 example above). See also
+ <a href="#bpc-5_2_3">5.2.3</a>.
+ </div>
+ <div id="bpc-5_3_2" class="rule">5.3.2 BPC servers SHOULD support requests for information about a known BPC
+ 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 BPC URL. For example, if there is a BPC URL <code><containerURL>,</code> the URL to request the
+ non-membership properties would be <code><containerURL>?non-member-properties</code>.
+ See section <a href="#bpc-get_non_member_props">5.1.2 Retrieving Non-member Properties</a> for
+ additional details. A BPC 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).
+ </div>
+ <div id="bpc-5_3_3" class="rule">5.3.3 A BPC server that does not support a request to retrieve the first
+ page resource representation via a known BPC as “<code><containerURL></code>”,
+ the Request-URI of “<code><containerURL>?firstPage</code>”, MUST return a HTTP status code 404 (Not
+ Found).
+ </div>
+ <div id="bpc-5_3_4" class="rule">5.3.4 BPC servers SHOULD support requests for splitting large BPCs into
+ pages indicated by a client supplying the token “<code>firstPage</code>”
+ on the query component of the BPC URL. For example, if there is a BPC
+ 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="#bpc-paging">5.1.3 titled “Paging”</a> for additional details.
+ </div>
+ <div id="bpc-5_3_5" class="rule">5.3.5 BPC servers MAY split the response representation of a BPC 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="#bpc-paging">5.1.3 Paging</a> for
+ additional details.
+ </div>
+ <div id="bpc-5_3_5_1" class="rule">5.3.5.1 BPC servers that initiate paging SHOULD respond to requests for a BPC
+ 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="bpc-5_3_6" class="rule">5.3.6 BPC servers that support paging MUST include in the page
+ representation a representation for the BPC, such that:
+ </div>
+ <div id="bpc-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>bp: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>bp:pageOf,</code>
+ and object is the URL of the BPC.
+ </div>
+ <div id="bpc-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>bp:nextPage</code> and
+ object being the URL for the subsequent page.
+ </div>
+ <div id="bpc-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>bp:nextPage</code> and object being <code>rdf:nil</code>.
+ </div>
+ <div id="bpc-5_3_7" class="rule">5.3.7 BPC servers MAY represent the members of a paged BPC in a sequential
+ order. The order MUST be specified using the <code>bp:containerSortPredicates</code>
+ predicate whose subject is that of the page and object is a list of
+ BPC ordinal predicates. The default ordering is ascending. The only
+ ordinal predicate literal data types supported are those as defined
+ by SPARQL SELECT’s ORDER BY clause [SPARQL].
+ </div>
+ <div id="bpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>bp: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="#bpc-ordering">5.1.4 Ordering</a> for
+ additional details.
+ </div>
+ <p>The Basic Profile does not define how clients
+ discover BPCs.</p>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_POST">HTTP POST</h2>
+ <div id="bpc-5_4_1" class="rule">5.4.1 BPC clients SHOULD create resources by submitting a representation as
+ the entity body of the HTTP POST to a known BPC. BPC servers MUST
+ respond with status code 201 (Created) and the <code>Location</code>
+ header set to the new resource’s URL.
+ </div>
+ <div id="bpc-5_4_2" class="rule">5.4.2 After a successful HTTP POST request to a BPC, the new resource MUST
+ appear as a member of the BPC until the new resource is deleted or
+ removed by other methods. A BPC MAY also contain resources that were
+ added through other means - for example through the user interface of
+ the site that implements the BPC.
+ </div>
+ <div id="bpc-5_4_3" class="rule">5.4.3 BPC servers MAY accept an HTTP POST of non-RDF representations for
+ creation of any kind of resource, for example binary resources.
+ </div>
+ <div id="bpc-5_4_4" class="rule">5.4.4 For servers that support create, BPC servers MUST create a BPR from a
+ RDF representation in the request entity body.
+ </div>
+ <div id="bpc-5_4_5" class="rule">5.4.5 BPC 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 id="bpc-5_4_6" class="rule">5.4.6 For BPCs, servers MUST accept a request entity body with a content
+ type of <code>application/rdf+xml</code>.
+ </div>
+ <div id="bpc-5_4_7" class="rule">5.4.7 For BPCs, BPR servers SHOULD accept a request with an entity body
+ content type of <code>text/turtle</code>.
+ </div>
+ <div id="bpc-5_4_8" class="rule">5.4.8 For RDF representations, BPC servers MUST interpret the null relative
+ URI for the subject of triples in the BPR 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” BPR, 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>
+ <div id="bpc-5_4_9" class="rule">5.4.9 BPC servers SHOULD assign the subject URI for the resource to be
+ created using server application specific rules.
+ </div>
+ <div id="bpc-5_4_10" class="rule">5.4.10 BPC servers SHOULD allow clients to create new resources without
+ requiring detailed knowledge of application-specific constraints.
+ Some BPC servers put restrictions on representations – for example,
+ the range of <code>rdf:type</code>, datatypes of
+ predicates and number of occurrences of predicates in triples - but
+ server enforcement of detailed, domain-specific constraints will
+ greatly restrict the types of clients that can create resources and
+ therefore discouraged.
+ </div>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_PUT">HTTP PUT</h2>
+ <div id="bpc-5_5_1" class="rule">5.5.1 BPC servers SHOULD NOT allow HTTP PUT to update a BPC’s members and
+ if the server receives such a request, it SHOULD respond with a 409
+ (Conflict) status code.
+ </div>
+ <div id="bpc-5_5_2" class="rule">5.5.2 BPC servers MAY allow updating BPC non-membership properties using
+ HTTP PUT on <code><containerURL>?non-member-properties</code>, which
+ MAY exclude server managed properties such as <code>bp:membershipSubject</code> and <code>bp:membershipPredicate</code>.
+ </div>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_DELETE">5.6 HTTP DELETE</h2>
+ <div id="bpc-5_6_1" class="rule">5.6.1 If a BPC server supports deletion of the BPC, the server MAY also
+ delete the resources that are referenced as its contents.
+ </div>
+ <div id="bpc-5_6_2" class="rule">5.6.2 When a resource that is contained in a BPC (for example referenced by
+ a membership triple) is deleted, the server MUST also remove it from
+ the BPC that was used to create it and SHOULD remove it from any
+ other containers that reference it that the server manages and
+ persists.
+ </div>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_HEAD">HTTP HEAD</h2>
+ <p>There are no additional requirements on HTTP
+ HEAD.</p>
+</section>
+
+<section>
+<h2 id="bpc-HTTP_PATCH">HTTP PATCH</h2>
+ <div id="bpc-5_8_1" class="rule">5.8.1 BPC servers are RECOMMENDED to support HTTP PATCH as the preferred
+ method for updating BPC non-membership properties.
+ </div>
+</section>
+</section>
+
+
+<section class='appendix'>
+<h2 id="normative_refs">Normative References</h2>
+ <div><dl>
+ <dt>Dublin Core</dt>
+ <dd><cite>
+ <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/">Dublin Core
+ Metadata Initiative</a></cite>
+ <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/"> Terms
+ </a>, DCMI Recommendation, 11 October 2010. This version is
+ http://dublincore.org/documents/2010/10/11/dcmi-terms/. The latest
+ version is http://dublincore.org/documents/dcmi-terms/.
+ </dd>
+
+ <dt>RDF</dt>
+ <dd><cite><a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">Resource Description Framework (RDF): Concepts and Abstract Syntax</a></cite>, Klyne G.,
+ Carroll J. (Editors), W3C Recommendation, 10 February 2004.
+ This version is http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.
+ The <a href="http://www.w3.org/TR/rdf-concepts/">latest version</a> is http://www.w3.org/TR/rdf-concepts/.</dd>
+
+ <dt>RFC2119</dt>
+ <dd><cite>
+ <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119:
+ Key words for use in RFCs to Indicate Requirement Levels
+ </a></cite>, Scott Bradner, 1997. (See
+ http://www.ietf.org/rfc/rfc2119.txt)
+ </dd>
+
+ <dt>RFC2616</dt>
+ <dd><cite>
+ <a href="http://www.ietf.org/rfc/rfc2616.txt">Hypertext
+ Transfer Protocol - HTTP/1.1
+ </a></cite>. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
+ Berners-Lee, June 1999. Available at
+ http://www.ietf.org/rfc/rfc2616.txt.
+ </dd>
+
+ <dt>RFC3986</dt>
+ <dd><cite>
+ <a href="http://www.apps.ietf.org/rfc/rfc3986.html">Uniform
+ Resource Identifier (URI): Generic Syntax
+ </a></cite>, Berners-Lee, Fielding, Masinter, January 2005.
+ </dd>
+
+ <dt>RFC5789</dt>
+ <dd><cite>
+ <a href="http://tools.ietf.org/html/rfc5789">PATCH Method for HTTP
+ </a></cite>, L Dusseault, J. Snell, March 2010. Available at
+ http://tools.ietf.org/html/rfc5789
+ </dd>
+
+ <dt>RFC3987</dt>
+ <dd><cite>
+ <a href="http://www.ietf.org/rfc/rfc3987.txt">Internationalized
+ Resource Identifiers (IRIs)
+ </a></cite>, Duerst, Suignard, January 2005.
+ </dd>
+
+ <dt>SPARQL-UPDATE</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TR/2010/WD-sparql11-update-20100126/">
+ SPARQL 1.1 Update</a></cite>, S. Schenk, P. Gearon, Editor,
+ W3C Working Draft, 26 January 2010,
+ http://www.w3.org/TR/2010/WD-sparql11-update-20100126/. <a
+ href="http://www.w3.org/TR/sparql11-update/">Latest version
+ </a> available at http://www.w3.org/TR/sparql11-update/.
+ </dd>
+ </dl>
+</section>
+
+<section class='appendix'>
+<h2 id="informative_refs">Informative References</h2>
+ <dl>
+ <dt>4Rules</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/DesignIssues/LinkedData.html">Linked Data
+ Design Issues</a></cite>, Tim Berners-Lee, 27 July 2006, <a
+ href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html
+ </a>
+ </dd>
+
+ <dt>DC-RDF</dt>
+ <dd><cite>
+ <a href="http://dublincore.org/documents/dc-rdf/">Expressing
+ Dublin Core metadata using the Resource Description Framework
+ (RDF)</a></cite>, M. Nilsson and all, 14 January 2008,
+ http://dublincore.org/documents/2008/01/14/dc-rdf/. Latest available
+ at: http://dublincore.org/documents/dc-rdf/.
+ </dd>
+
+ <dt>HTML 4.01</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TR/html4/">HTML 4.01
+ Specification</a></cite>, D. Raggett, A. Le Hors, and I.
+ Jacobs, 1999. (See http://www.w3.org/TR/html4/)
+ </dd>
+
+<dt>IANA</dt>
+<dd><cite><a href="http://www.iana.org/assignments/media-types/index.html">Internet Assigned Numbers Authority
+(IANA)</a></cite> MIME Media Types, http://www.iana.org/assignments/media-types/index.html</dd>
+
+ <dt>LinkedData</dt>
+ <dd><cite><a
+ href="http://www.w3.org/standards/semanticweb/data">Linked Data at W3C</a></cite>,
+ http://www.w3.org/standards/semanticweb/data</a>
+ </dd>
+
+ <dt>OSLC</dt>
+ <dd><cite><a href="http://open-services.net/">Open Services for Lifecycle Collaboration (OSLC)</a></cite>, http://open-services.net</dd>
+
+ <dt>RDF Primer</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210">Resource
+ Description Framework (RDF): Concepts and Abstract Syntax
+ </a></cite>, Klyne G., Carroll J. (Editors), W3C Recommendation, 10 February
+ 2004. This version is
+ http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. The <a href="http://www.w3.org/TR/rdf-primer/">latest
+ version</a> is http://www.w3.org/TR/rdf-primer/.
+ </dd>
+
+ <dt>RDF-MT</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210/">RDF
+ Semantics</a></cite>, P. Hayes, Editor, W3C
+ Recommendation, 10 February 2004,
+ http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. <a
+ href="http://www.w3.org/TR/rdf-mt/">Latest version
+ </a> available at http://www.w3.org/TR/rdf-mt/.
+ </dd>
+
+ <dt>RDF-REST</dt>
+ <dd><cite><a href="http://www.w3.org/2001/sw/wiki/index.php?title=REST">RDF Simple Data Interface Protocol – Level Zero</a></cite>,
+ Latest version available at:
+ http://www.w3.org/2001/sw/wiki/index.php?title=REST</dd>
+
+ <dt>REST</dt>
+ <dd><cite>
+ <a
+ href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm">Representational
+ State Transfer (REST)</a></cite>, R. Fielding, Ph.D. dissertation,
+ 2000, <a
+ href="http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm">Latest version
+ </a> available at
+ http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
+ .
+ </dd>
+
+ <dt>RW LinkedData</dt>
+ <dd><cite><a href="http://www.w3.org/DesignIssues/ReadWriteLinkedData.html">Read-Write Linked Data</a></cite>,
+ Berners-Lee, August 2009, http://www.w3.org/DesignIssues/ReadWriteLinkedData.html</dd>
+
+ <dt>SPARQL</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/">SPARQL Query
+ Language for RDF</a></cite>, E. Prud'hommeaux, A. Seaborne,
+ Editor, W3C Recommendation, 15 January 2008,
+ http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. <a
+ href="http://www.w3.org/TR/rdf-sparql-query/">Latest version
+ </a> available at http://www.w3.org/TR/rdf-sparql-query/.
+ </dd>
+
+ <dt>SPARQL-HTTP</dt>
+ <dd>
+ SPARQL 1.1 Graph Store HTTP Protocol, Latest version available at <a
+ href="http://www.w3.org/2009/sparql/docs/http-rdf-update/">http://www.w3.org/2009/sparql/docs/http-rdf-update/
+ </a>
+ </dd>
+
+ <dt>TURTLE</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110328/">Turtle -
+ Terse RDF Triple Language
+ </a></cite>, D. Beckett, T. Berners-Lee, Team Submission, 28 March 2011,
+ http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110328/. Latest
+ version available at http://www.w3.org/TeamSubmission/turtle/.
+ </dd>
+
+ <dt>WEBARCH</dt>
+ <dd><cite>
+ <a href="http://www.w3.org/TR/2004/REC-webarch-20041215/">Architecture
+ of the World Wide Web, Volume One</a></cite>
+ , N. Walsh, I. Jacobs, Editors,
+ W3C Recommendation, 15 December 2004,
+ http://www.w3.org/TR/2004/REC-webarch-20041215/. <a
+ href="http://www.w3.org/TR/webarch/">Latest version
+ </a> available at http://www.w3.org/TR/webarch/.
+ </dd>
+ </dl>
+</section>
+
+<section class='appendix informative' id="history">
+<h1>Change History</h1>
+<p>2012-09-18
+Initial ReSpec'ing of <a href="http://www.w3.org/Submission/ldbp/">Member Submission - Linked Data Basic Profile 1.0</a>
+</p>
+</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>Fix up h3 references which are hacked div's at the moment</li>
+ <li>References don't follow ReSpec's handy format</li>
+ <li>What URIs should be used for editor's and PWD? Currently we 'borrow' open-services.net</li>
+</ul>
+</section>
+
+ <section class='appendix informative'>
+ <h2>Acknowledgements</h2>
+
+ <p>The following people have been instrumental in providing thoughts, feedback,
+ reviews, criticism and input in the creation of this specification:</p>
+
+ <ul>
+ <li>Martin P. Nally (IBM)</li>
+ <li>John Arwe (IBM)</li>
+ <li>Arnaud le Hors (IBM)</li>
+ </ul>
+ </section>
+ </body>
+</html>