--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldbp.html Tue Sep 18 13:39:21 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>
--- a/ldp.html Tue Sep 18 13:35:33 2012 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1359 +0,0 @@
-<!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>