New version changed to NOTE; also added ref to LDP 1.o in abstract.
authorcburleso
Fri, 22 Aug 2014 08:57:40 -0500
changeset 751 4835441f2e2f
parent 750 58fcc9c31341
child 752 64f7014ed8cf
New version changed to NOTE; also added ref to LDP 1.o in abstract.
TR/NOTE-ldp-bp-20140829/ldp-bp.html
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/NOTE-ldp-bp-20140829/ldp-bp.html	Fri Aug 22 08:57:40 2014 -0500
@@ -0,0 +1,1209 @@
+<!DOCTYPE html>
+<html prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" content="en" property="dcterms:language" about="" typeof="bibo:Document w3p:NOTE" dir="ltr" lang="en"><head>
+<title>Linked Data Platform Best Practices and Guidelines</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://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script -->
+
+
+<style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+}
+
+dfn {
+    font-weight:    bold;
+}
+
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+}
+
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+}
+
+a.bibref {
+    text-decoration:    none;
+}
+
+cite .bibref {
+    font-style: normal;
+}
+
+code {
+    color:  #C83500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+}
+
+a .secno, a .figno {
+    color:  #000;
+}
+
+ul.tof, ol.tof {
+    list-style: none outside none;
+}
+
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+}
+
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+}
+
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+}
+
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+}
+
+.section dd > p:last-child {
+    margin-bottom: 0;
+}
+
+.section dd {
+    margin-bottom:  1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+}
+
+@media print {
+    .removeOnSave {
+        display: none;
+    }
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+    min-width: 7.5em;
+    color: #b9ab2d;
+}
+div.example-title span {
+    text-transform: uppercase;   
+}
+aside.example, div.example, div.illegal-example {
+    padding: 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+    border-color: #e0cb52;
+    background: #fcfaee;    
+}
+
+aside.example div.example {
+    border-left-width: .1em;
+    border-color: #999;
+    background: #fff;
+}
+aside.example div.example div.example-title {
+    color: #999;
+}
+
+</style>
+
+<link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-NOTE" />
+
+<!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+
+
+
+<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+  
+  <p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p>
+
+  <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Best Practices and Guidelines</h1>
+  
+  <h2 id="w3c-working-group-note-29-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-29T05:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-29">29 August 2014</time></h2>
+  <dl>
+    
+      <dt>This version:</dt>
+      <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/">http://www.w3.org/TR/2014/NOTE-ldp-bp-20140829/</a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href="http://www.w3.org/TR/ldp-bp/">http://www.w3.org/TR/ldp-bp/</a></dd>
+    
+    
+      <dt>Latest editor's draft:</dt>
+      <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html</a></dd>
+    
+    <dt>Editors:</dt>
+    <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Cody Burleson" href="http://codyburleson.com/">Cody Burleson</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://base22.com/">Base22</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Miguel Esteban Gutiérrez" href="http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban">Miguel Esteban Gutiérrez</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Nandana Mihindukulasooriya" href="http://www.nandana.org/">Nandana Mihindukulasooriya</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oeg-upm.net/">Ontology Engineering Group, Universidad Politécnica de Madrid</a></span>
+</dd>
+    
+  </dl>
+    
+      <p class="copyright">
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+        2014
+        
+        <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+        (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), 
+        
+        All Rights Reserved.
+        
+        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+        <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+        
+          <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+        
+        rules apply.
+      </p>
+    
+  
+  <hr>
+</div>
+
+	<section rel="bibo:Chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2><p>This document provides best practices
+		and guidelines for implementing Linked Data Platform [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] servers
+		and clients.</p></section><section rel="bibo:Chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">Status of This Document</h2>
+  
+    
+      
+        <p>
+          <em>This section describes the status of this document at the time of its publication.
+          Other documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the
+          latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+          http://www.w3.org/TR/.</em>
+        </p>
+        
+		
+	
+        <p>
+          This document was published by the <a href="http://www.w3.org/2012/ldp/wiki/Main_Page">Linked Data Platform Working Group</a> as a Working Group Note.
+          
+          
+            If you wish to make comments regarding this document, please send them to 
+            <a href="mailto:public-ldp@w3.org">public-ldp@w3.org</a> 
+            (<a href="mailto:public-ldp-request@w3.org?subject=subscribe">subscribe</a>,
+            <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
+          
+          
+          
+          
+            All comments are welcome.
+          
+        </p>
+        
+        
+          <p>
+            Publication as a Working Group Note does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr>
+            Membership. This is a draft document and may be updated, replaced or obsoleted by other
+            documents at any time. It is inappropriate to cite this document as other than work in
+            progress.
+          </p>
+        
+        
+        
+        <p>
+          
+            This document was produced by a group operating under the 
+            <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent
+            Policy</a>.
+          
+          
+          
+            
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent
+              disclosures</a> 
+            
+            made in connection with the deliverables of the group; that page also includes
+            instructions for disclosing a patent. An individual who has actual knowledge of a patent
+            which the individual believes contains
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+            Claim(s)</a> must disclose the information in accordance with
+            <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+          
+          
+        </p>
+        
+          <p>This document is governed by the <a id="w3c_process_revision" href="http://www.w3.org/2014/Process-20140801/">1 August 2014 <abbr title="World Wide Web Consortium">W3C</abbr> Process Document</a>.
+          </p>
+        
+        
+      
+    
+  
+</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" class="toc"><li class="tocline"><a class="tocxref" href="#intro"><span class="secno">1. </span>About this Document</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#impetus"><span class="secno">1.1 </span>Impetus</a></li><li class="tocline"><a class="tocxref" href="#terminology"><span class="secno">1.2 </span>Terminology</a></li><li class="tocline"><a class="tocxref" href="#prerequisites-and-assumptions"><span class="secno">1.3 </span>Prerequisites and Assumptions</a></li></ul></li><li class="tocline"><a class="tocxref" href="#best-practices"><span class="secno">2. </span>Best Practices</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#predicate-uris-should-be-http-urls"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</a></li><li class="tocline"><a class="tocxref" href="#use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
+				concept of type in LDPRs</a></li><li class="tocline"><a class="tocxref" href="#use-relative-uris"><span class="secno">2.3 </span>Use relative URIs</a></li><li class="tocline"><a class="tocxref" href="#avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</a></li><li class="tocline"><a class="tocxref" href="#represent-container-membership-with-hierarchical-uris"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</a></li><li class="tocline"><a class="tocxref" href="#include-a-trailing-slash-in-container-uris"><span class="secno">2.6 </span>Include a trailing slash in container URIs</a></li><li class="tocline"><a class="tocxref" href="#use-fragments-as-relative-identifiers"><span class="secno">2.7 </span>Use fragments as relative identifiers</a></li><li class="tocline"><a class="tocxref" href="#prefer-standard-datatypes"><span class="secno">2.8 </span>Prefer standard datatypes</a></li><li class="tocline"><a class="tocxref" href="#re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
+				(re-)inventing duplicates</a></li><li class="tocline"><a class="tocxref" href="#use-qvalues-properly"><span class="secno">2.10 </span>Use qvalues properly</a></li><li class="tocline"><a class="tocxref" href="#respond-with-primary-urls-and-use-them-for-identity-comparison"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</a></li><li class="tocline"><a class="tocxref" href="#representing-relationships-between-resources"><span class="secno">2.12 </span>Representing relationships between resources</a></li><li class="tocline"><a class="tocxref" href="#minimize-server-specific-constraints"><span class="secno">2.13 </span>Minimize server-specific constraints</a></li></ul></li><li class="tocline"><a class="tocxref" href="#guidelines"><span class="secno">3. </span>Guidelines</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#containers-are-not-limited-to-membership-and-containment-triples"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</a></li><li class="tocline"><a class="tocxref" href="#finding-established-vocabularies"><span class="secno">3.2 </span>Finding established vocabularies</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
+
+	
+
+
+	<section rel="bibo:Chapter" resource="#intro" typeof="bibo:Chapter" id="intro">
+
+		<!--OddPage--><h2 id="h2_intro" role="heading" aria-level="1"><span class="secno">1. </span>About this Document</h2>
+
+		<section id="impetus">
+
+			<h3 id="h3_impetus" role="heading" aria-level="2"><span class="secno">1.1 </span>Impetus</h3>
+
+			<p>While writing the Linked Data Platform Specification, the
+				authors and contributors felt compelled to share common conventions
+				and valuable lessons-learned. Yet, at the same time, they did not
+				wish to impose or imply unnecessary restrictions, or to make the
+				formal specification unnecessarily verbose. This document, along
+				with the LDP Primer [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>], was therefore developed to
+				provide additional context. Drawing upon the professional
+				experiences of its authors and contributors, research into the rich
+				history of related technologies, and continuous feedback from the
+				community at large, it aims to help system implementers avoid common
+				pitfalls, improve quality, and achieve greater interoperability with
+				other Linked Data systems.</p>
+
+		</section>
+
+		<section id="terminology">
+
+			<h3 id="h3_terminology" role="heading" aria-level="2"><span class="secno">1.2 </span>Terminology</h3>
+
+			<p>For the purposes of this document, it is useful to
+				make a minor, yet important distinction between the term 'best
+				practice' and the term 'guideline'. We define and differentiate 
+				the terms as follows:</p>
+
+			<dl>
+				<dt>best practice</dt>
+				<dd>An implementation practice (method or technique) that has
+					consistently shown results superior to those achieved with other
+					means and that is used as a benchmark. Best practices within this
+					document apply specifically to the ways that LDP servers and
+					clients are implemented as well as how certain resources are
+					prepared and used with them. In this document, the best practices
+					might be used as a kind of check-list against which an implementer
+					can directly evaluate a system's design and code. Lack of adherence
+					to any given best practice, however, does not necessarily imply a
+					lack of quality; they are recommendations that are said to be
+					'best' in most cases and in most contexts, but not all. A best
+					practice is always subject to improvement as we learn and evolve
+					the Web together.</dd>
+				<dt>guideline</dt>
+				<dd>A tip, a trick, a note, a suggestion, or answer to a
+					frequently asked question. Guidelines within this document provide
+					useful information that can advance an implementer's knowledge and
+					understanding, but that may not be directly applicable to an
+					implementation or recognized by consensus as a 'best practice'.</dd>
+			</dl>
+
+			<p>Please see the Terminology section in Linked Data Platform 1.0
+				[<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] as well as the Linked Data Glossary [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] for
+				definitions to a variety of terms used in this document and related
+				to the Linked Data sphere of knowledge.</p>
+
+		</section>
+
+		<section id="prerequisites-and-assumptions">
+
+			<h3 id="h3_prerequisites-and-assumptions" role="heading" aria-level="2"><span class="secno">1.3 </span>Prerequisites and Assumptions</h3>
+
+			<p>
+				Implementers should have at least a general familiarity with the <a href="#informative-references">informative references</a> cited in
+				this document - especially the following:
+			</p>
+
+			<ul>
+				<li><strong>RDF Vocabulary Description Language 1.0: RDF Schema</strong> 
+					[<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] - The Resource Description Framework
+					(RDF) is a general-purpose language for representing information in
+					the Web and it is the defacto language for expressing Linked Data.
+					This specification describes how to use RDF to describe RDF
+					vocabularies.</li>
+				<li><strong>RDF Primer 1.1</strong> [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] - This Primer is designed to
+					provide the reader with the basic knowledge required to effectively
+					use RDF. It introduces the basic concepts of RDF and describes its
+					XML syntax. It describes how to define RDF vocabularies using the
+					RDF Vocabulary Description Language, and gives an overview of some
+					deployed RDF applications. It also describes the content and
+					purpose of other RDF specification documents.</li>
+				<li><strong>Turtle - Terse RDF Triple Language</strong>
+					[<cite><a href="#bib-TURTLE" class="bibref">TURTLE</a></cite>] - defines a textual syntax for RDF called Turtle that
+					allows RDF graphs to be completely written in a compact and natural
+					text form, with abbreviations for common usage patterns and
+					datatypes. RDF examples used in this document are expressed in
+					Turtle.</li>
+				<li><strong>Linked Data Glossary</strong> [<cite><a href="#bib-LD-GLOSSARY" class="bibref">LD-GLOSSARY</a></cite>] - a
+					useful glossary containing terms defined and used to describe
+					Linked Data, and its associated vocabularies and best practices for
+					publishing structured data on the Web.</li>
+				<li><strong>Linked Data Platform 1.0</strong> [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] - the
+					formal specification for the LDP read-write Linked Data
+					architecture, based on HTTP access to web resources that describe
+					their state using the RDF data model.
+				</li><li><strong>Linked Data Platform 1.0 Test Cases</strong>
+					[<cite><a href="#bib-LDP-TESTS" class="bibref">LDP-TESTS</a></cite>] - a standard set of tests provided by the <abbr title="World Wide Web Consortium">W3C</abbr>, which
+					can be use to verify an implementation's conformance to the LDP
+					specification.</li>
+				<li><strong>Linked Data Platform Primer</strong> [<cite><a href="#bib-LDP-PRIMER" class="bibref">LDP-PRIMER</a></cite>]
+					- an introduction to LDP, which describes the basic concepts of LDP
+					such as Linked Data Platform Resources (LDPRs), Linked Data
+					Platform Containers (LDPCs), and their affordances. The Primer
+					provides a running example illustrating how an LDP client can
+					interact with an LDP server in the context of a read-write Linked
+					Data application (i.e. how to use HTTP for accessing, updating,
+					creating and deleting resources from servers that expose their
+					resources as Linked Data).</li>
+				<li><strong>Linked Data Platform Use Cases and
+						Requirements</strong> [<cite><a href="#bib-LDP-UCR" class="bibref">LDP-UCR</a></cite>] - a set of user stories, use cases,
+					scenarios and requirements that motivate a simple read-write Linked
+					Data architecture, based on HTTP access to web resources that
+					describe their state using RDF.</li>
+			</ul>
+
+		</section>
+
+	</section>
+
+	<section id="best-practices">
+
+		<!--OddPage--><h2 id="h2_best-practices" role="heading" aria-level="1"><span class="secno">2. </span>Best Practices</h2>
+
+		<section id="predicate-uris-should-be-http-urls">
+
+			<h3 id="h3_predicate-uris-should-be-http-urls" role="heading" aria-level="2"><span class="secno">2.1 </span>Predicate URIs should be HTTP URLs</h3>
+
+			<p>URIs are used to uniquely identify resources and URLs are used
+				to locate resources on the Web. That is to say that a URL is
+				expected to resolve to an actual resource, which can be retrieved
+				from the host. A URI, on the other hand, may also be a URL, but it
+				does not have to be; it may refer to something that has no
+				retrievable representation.</p>
+
+			<p>One of the fundamental ideas behind Linked Data is that the
+				things referred to by HTTP URIs can actually be looked up
+				("dereferenced"). This important principle was originally
+				outlined by Tim Berners-Lee as rule #2 of "the four rules"
+				for linking data [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>]. It is therefore ideal that predicate
+				URIs identify resources with representations that are retrievable. LDP
+				servers should at least provide [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>] representations of
+				these predicates where possible.</p>
+
+			<p>Of course, it is also a common practice to reuse properties
+				from open vocabularies that are publicly available. In this case,
+				implementers have no control over the result when attempting to
+				dereference the URI. For this reason, publishers who wish to make
+				their vocabularies useful for linking data should strive to provide
+				a retrievable representation of the properties their vocabularies
+				define. Consequently, implementers are also expected to use this
+				practice as a benchmark for which to judge the efficacy of a
+				vocabulary's use for linking data.</p>
+
+		</section>
+
+		<section id="use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs">
+
+			<h3 id="h3_use-and-include-the-predicate-rdf-type-to-represent-the-concept-of-type-in-ldprs" role="heading" aria-level="2"><span class="secno">2.2 </span>Use and include the predicate rdf:type to represent the
+				concept of type in LDPRs</h3>
+
+			<p>
+				It is often very useful to know the type (class) of an LDPR, though
+				it is not essential to work with the interaction capabilities that
+				LDP offers. Still, to make data more useful in the broadest context,
+				type should be explicitly defined using the <code>rdf:type</code>
+				predicate defined by [<cite><a href="#bib-RDF-SCHEMA" class="bibref">RDF-SCHEMA</a></cite>].
+			</p>
+
+			<p>This provides a way for clients to easily determine the type(s)
+				of a resource without having to perform additional processing or
+				make additional HTTP requests. For example, clients that cannot
+				infer the type because they do not support inferencing can benefit
+				from this explicit declaration.</p>
+
+			<div class="example"><div class="example-title"><span>Example 1</span>: Representation of an LDPR with explicit declaration of rdf:type</div><pre class="example">@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
+@prefix contact: &lt;http://www.w3.org/2000/10/swap/pim/contact#&gt;.
+
+&lt;http://www.w3.org/People/EM/contact#me&gt; 
+  a contact:Person;
+  contact:fullName "Eric Miller";
+  contact:mailbox &lt;mailto:em@w3.org&gt;;
+  contact:personalTitle "Dr.".</pre></div>
+
+			<p>The token 'a' in the predicate position of a Turtle triple represents the IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#type. 
+			In the example above, therefore, <code>a contact:Person</code> is the same as <code>rdf:type contact:Person</code> or the fully-qualified form, <code>&lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#type&gt; contact:Person</code>.</p>
+
+		</section>
+
+		<section id="use-relative-uris">
+
+			<h3 id="h3_use-relative-uris" role="heading" aria-level="2"><span class="secno">2.3 </span>Use relative URIs</h3>
+
+			<!-- http://www.w3.org/2012/ldp/track/issues/29 -->
+
+			<p>Relative URIs are useful to the Linked Data Platform in much
+				the same ways that relative URLs [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>] have been useful to
+				traditional web systems. Since the things referred to by Linked Data
+				URIs should provide a retrievable representation [<cite><a href="#bib-LD-DI" class="bibref">LD-DI</a></cite>], Linked
+				Data URIs are usually also URLs; they locate rather than just
+				identify. As such, the utilitarian value of relative URLs still
+				applies; especially since the LDP Container model promotes
+				hierarchical representations.</p>
+
+			<p>Implementers should therefore align the function of relative
+				URIs in LDP with those of traditional relative URLs where possible
+				and appropriate. Aside from giving developers the comfort and
+				convenience of familiarity, they provide many of the same
+				advantages.</p>
+
+			<dl>
+				<dt>Relative URIs are shorter than absolute URIs.</dt>
+				<dd>
+					<p>In many cases, this can aid development by making code and
+						RDF easier for humans to read. It can also reduce the size of
+						payloads, which in turn, can reduce network traffic and stress on
+						servers, while improving response times for end-users.</p>
+
+					<div class="example"><div class="example-title"><span>Example 2</span>: Representation of http://example.org/container1/ with absolute URIs</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;http://example.org/container1/&gt;
+   a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains
+      &lt;http://example.org/container1/member1&gt;,
+      &lt;http://example.org/container1/member2&gt;,
+      &lt;http://example.org/container1/member3&gt;.</pre></div>
+
+
+					<div class="example"><div class="example-title"><span>Example 3</span>: Representation of http://example.org/container1/ with relative URIs</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;&gt; a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt; .</pre></div>
+
+				</dd>
+
+				<dt>Relative URIs can make resources more portable.</dt>
+				<dd>When information which is already known from the context of
+					the base resource's retrieval is omitted, there can be less
+					information to modify when its location changes. This can make
+					copying resources to new servers or to a new position in a
+					containment hierarchy easier; in the preceding example, 
+					a process that clones just the container need not adjust any of
+					its member URIs.
+					</dd>
+
+				<dt>Relative URIs are convenient during development.</dt>
+				<dd>During development the scheme and network location
+					information in a URI may either be unknown or likely to change. The
+					commonly used 'localhost' for example, is better expressed by the
+					server name or a domain name. Developers often experience less
+					hassle by omitting this information. Additionally, the hierarchy
+					implied by a relative URI may be mimicked in a server file system,
+					which can help developers find and work with information, even when
+					the server isn't running.</dd>
+
+				<dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
+				<dd>
+					RESTful URLs are often defined by a pattern of hierarchical
+					'collections', which clients interact with in very logical ways.
+					For example, when creating a new resource the client does not
+					typically know the name of the resource until after a successful
+					POST to a collection's URL. A POST to
+					<code>/people/</code>
+					for example, may create the resource
+					<code>/people/1</code>
+					. LDP Containers are such collections whose URIs can benefit from
+					the same model, which in some implementations, may actually be
+					crucial.
+				</dd>
+			</dl>
+		</section>
+
+		<section id="avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution">
+			<h3 id="h3_avoid-dot-segments-in-uris-of-posted-content-or-use-with-caution" role="heading" aria-level="2"><span class="secno">2.4 </span>Avoid dot-segments in URIs of POSTed content or use with caution</h3>
+
+			<p>The semantics of dot-segments (eg. <code>../</code>) within relative URIs may be implied by other 
+			specifications and by common historical use, but in the case of LDP, additional consideration is required.</p>
+
+			<p>The LDP specification states that... </p><blockquote>LDP servers <em title="MUST" class="rfc2119">MUST</em> assign the default base-URI for [<cite><a href="#bib-RFC3987" class="bibref">RFC3987</a></cite>]
+ relative-URI resolution 
+			to be the HTTP Request-URI when the resource already exists, and to 
+the URI of the created resource when the request results in the creation
+ 
+			of a new resource.</blockquote> It follows from this definition that use of <code>../</code>
+ and other non-null relative URI constructs during 
+			POST can cause the posted content to be referring to resources in a 
+manner the client might not be able to predict. 
+			Dot-segments should therefore be avoided unless the client knows 
+specifically what can be expected of the given implementation 
+			and/or deployment.<p></p>
+		</section>
+
+
+		<section id="represent-container-membership-with-hierarchical-uris">
+
+			<h3 id="h3_represent-container-membership-with-hierarchical-uris" role="heading" aria-level="2"><span class="secno">2.5 </span>Represent container membership with hierarchical URIs</h3>
+
+			<p>Hierarchical URIs are good for containers because they enable
+				the use of relative URIs. They also promote easy interaction with
+				resources that are modeled to represent parent-child relationships
+				where the child logically belongs to the parent.</p>
+
+			<p>
+				One example of such a model can be found in the case of the
+				<code>oslc_cm:attachment</code>
+				container from the vocabularies defined by the <a href="http://open-services.net/">Open Service for Lifecycle
+					Management (OSLC)</a> community. The OSLC defines specifications and
+				vocabularies that are well-aligned to LDP. A resource in an OSLC
+				compliant change management system such as an issue or bug tracker
+				may have attachments represented by the
+				<code>oslc_cm:attachment</code>
+				container. The URI for such a container might be represented as
+				follows:
+			</p>
+
+			<p>
+				<code>http://example.org/bugs/2314/attachments/</code>
+			</p>
+
+			<p>From this URI, the URI of the parent resource which holds the
+				attachments is easily discerned. The base container for other
+				sibling resources can be discerned by moving up the hierarchy, which
+				is implied by the URI. Meta-data or binary content might be fetched
+				further down the hierarchy by using a URI such as the following:</p>
+
+			<p>
+				<code>http://example.org/bugs/2314/attachments/1</code>
+			</p>
+
+			<p>In addition to making the use of relative URIs possible,
+				hierarchical URIs make interacting with resources easier for users because
+				they represent the actual structure of the underlying graph.
+				Software agents (code acting on behalf of users [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>]) must be careful
+				before exploiting the structure of URIs, considering historical problems
+				when doing so ([<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], [<cite><a href="#bib-metaDataInURI" class="bibref">metaDataInURI</a></cite>]).
+				</p>
+
+		</section>
+
+
+		<section id="include-a-trailing-slash-in-container-uris">
+
+			<!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
+
+			<h3 id="h3_include-a-trailing-slash-in-container-uris" role="heading" aria-level="2"><span class="secno">2.6 </span>Include a trailing slash in container URIs</h3>
+
+			<p>When representing container membership with hierarchical URLs,
+				including the trailing slash in a container's URI makes it 
+				easier to use relative URIs.
+				Take the following container URI for example:</p>
+
+			<p>
+				<code>http://example.org/container1</code>
+			</p>
+
+			<p>It is more advantageous to use the following instead:</p>
+
+			<p>
+				<code>http://example.org/container1/</code>
+			</p>
+
+			<p>To illustrate the advantage, let's start with the following
+				container using absolute URIs:</p>
+
+			<div class="example"><div class="example-title"><span>Example 4</span>: A simple container</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;http://example.org/container1&gt;
+   a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains
+      &lt;http://example.org/container1/member1&gt;,
+      &lt;http://example.org/container1/member2&gt;,
+      &lt;http://example.org/container1/member3&gt;.</pre></div>
+
+			<p>Suppose now that we wish to reflect the same resource using
+				relative URIs. If the URI of the container includes the trailing
+				slash, we end up with a very elegant representation, as shown below.</p>
+
+			<div class="example"><div class="example-title"><span>Example 5</span>: Container URI is http://example.org/container1/</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;&gt; a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt; .</pre></div>
+
+			<p>But suppose that we omit the trailing slash, issued an HTTP
+				GET, and the container returned the representation shown above. This
+				could produce a graph that is equivalent to the following:</p>
+
+			<div class="example"><div class="example-title"><span>Example 6</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;http://example.org/container1&gt;
+   a a ldp:Container, ldp:BasicContainer;
+   dcterms:title "A very simple container";
+   ldp:contains
+      &lt;http://example.org/member1&gt;,
+      &lt;http://example.org/member2&gt;,
+      &lt;http://example.org/member3&gt;.</pre></div>
+
+			<p>That is not what was intended; the member URLs lack the 
+				<code>container</code> path segment.
+				The returned document would
+				have to be more verbose in order to be correct:</p>
+
+			<div class="example"><div class="example-title"><span>Example 7</span>: Container URI is http://example.org/container1</div><pre class="example">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
+@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
+@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
+
+&lt;&gt; a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains &lt;container1/member1&gt;, &lt;container1/member2&gt;, &lt;container1/member3&gt; .</pre></div>
+
+			<p>So, clearly, the better solution is to ensure that container
+				URIs end with a trailing slash.</p>
+
+		</section>
+
+
+		<section id="use-fragments-as-relative-identifiers">
+
+			<h3 id="h3_use-fragments-as-relative-identifiers" role="heading" aria-level="2"><span class="secno">2.7 </span>Use fragments as relative identifiers</h3>
+
+			<p>
+				Resource URIs are permitted to end with a fragment; the fragment
+				component is delimited from the rest of the URI because it is
+				introduced by a hash mark (<b><code>#</code></b>).
+				For this reason, URIs with non-empty fragments are often called hash URIs;
+				a hash URI identifies a subordinate or related resource [<cite><a href="#bib-RFC3986" class="bibref">RFC3986</a></cite>].
+			</p>
+
+			<p>
+				Take the URI,
+				<code>http://www.example.org/products#item10245</code>
+				, for example. The non-fragment portion of the URI is the part preceding the hash mark,
+				<code>http://www.example.org/products</code>
+				, and the fragment identifier is the part that follows,
+				<code>item10245</code>
+				.
+			</p>
+
+			<p>When expressing Linked Data Platform Resources in RDF,
+				fragments are useful because they can be expressed as relative URIs
+				on the document describing them. This is particularly handy for
+				describing multiple LDPRs whose representations are contained within
+				a single document.</p>
+
+			<p>
+				First, it provides the convenience and efficiency of brevity.
+				Suppose, for example, the resources foo, bar, and baz are
+				contained in the same document. Since serving all of the
+				descriptions in a single document is acceptable, we can mint
+				relative URIs within the document using the fragment identifier (
+				<code>&lt;#foo&gt;</code>
+				,
+				<code>&lt;#bar&gt;</code>
+				and
+				<code>&lt;#baz&gt;</code>
+				).  [<cite><a href="#bib-LDP" class="bibref">LDP</a></cite>] ensures that the default base URI is the document
+				URI (
+				<code>http://www.example.org/products</code>
+				), so the absolute URI for each is 
+				the base URI, plus the hash mark,
+				plus the fragment identifier.
+			</p>
+
+
+			<p>Second, it can help avoid certain complexities inherent with
+				other approaches. Achieving the same result using three independent
+				dereferenceable URIs could be more involved because multiple
+				documents would have to be published, perhaps also including the
+				setup of 303 redirects.</p>
+
+			<p>
+				<strong>See also:</strong>
+			</p>
+
+			<p>
+				<a href="http://www.w3.org/TR/cooluris">Cool URIs for the
+					Semantic Web</a>
+			</p><ul>
+				<li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
+				<li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
+			</ul>
+			<p></p>
+
+			<p>
+				<a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of
+					Web Architecture, URI References: Fragment Identifiers on URIs</a><br>
+				http://www.w3.org/DesignIssues/Fragment.html
+			</p>
+
+			<p>
+				<a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing
+					HTTP URIs</a><br>
+				http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
+			</p>
+
+		</section>
+
+
+		<section id="prefer-standard-datatypes">
+			<h3 id="h3_prefer-standard-datatypes" role="heading" aria-level="2"><span class="secno">2.8 </span>Prefer standard datatypes</h3>
+
+			<p>LDPR representations should 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 [<cite><a href="#bib-XMLSCHEMA11-2" class="bibref">XMLSCHEMA11-2</a></cite>] and [<cite><a href="#bib-RDF-PRIMER11" class="bibref">RDF-PRIMER11</a></cite>] should be used:</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>URI</th>
+						<th>Description</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
+						<td>Boolean type as specified by XSD Boolean</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
+						<td>Date type as specified by XSD date</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
+						<td>Date and Time type as specified by XSD dateTime</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
+						<td>Decimal number type as specified by XSD Decimal</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
+						<td>Double floating-point number type as specified by XSD
+							Double</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
+						<td>Floating-point number type as specified by XSD Float</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#hexBinary">http://www.w3.org/2001/XMLSchema#hexBinary</a></td>
+						<td>Arbitrary hex-encoded binary data as specified by XSD hexBinary</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
+						<td>Integer number type as specified by XSD Integer</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
+						<td>String type as specified by XSD String</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
+						<td>Binary type as specified by XSD Base64Binary</td>
+					</tr>
+					<tr>
+						<td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
+						<td>Literal XML value as specified by RDF</td>
+					</tr>
+				</tbody>
+			</table>
+
+		</section>
+
+
+		<section id="re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates">
+
+			<h3 id="h3_re-use-established-linked-data-vocabularies-instead-of-re--inventing-duplicates" role="heading" aria-level="2"><span class="secno">2.9 </span>Re-use established linked data vocabularies instead of
+				(re-)inventing duplicates</h3>
+
+			<p>
+				This section summarizes some well-known RDF vocabularies that should
+				be used in Linked Data Platform Resources wherever a resource needs
+				to use a predicate whose meaning matches one of these. For example,
+				if a resource has a description, and the application semantics of
+				that description is compatible with
+				<code>dcterms:description</code>
+				, then
+				<code>dcterms:description</code>
+				should be used. If needed, additional application-specific
+				predicates may be used. A specification for a domain may require one
+				or more of these properties for a particular resource type. The
+				Range column in the tables below identifies the defined
+				<code>rdfs:range</code>
+				for the properties.
+			</p>
+
+			<h3 id="common-properties">Common Properties</h3>
+
+			<p>
+				<strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
+			</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>Property</th>
+						<th>Range/DataType</th>
+						<th>Comment</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td>dcterms:contributor</td>
+						<td>dcterms:Agent</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:creator</td>
+						<td>dcterms:Agent</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:created</td>
+						<td>xsd:dateTime</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:description</td>
+						<td>rdf:XMLLiteral</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 element.</td>
+					</tr>
+					<tr>
+						<td>dcterms:identifier</td>
+						<td>rdfs:Literal</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:modified</td>
+						<td>xsd:dateTime</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:relation</td>
+						<td>rdfs:Resource</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>dcterms:subject</td>
+						<td>rdfs:Resource</td>
+						<td></td>
+					</tr>
+					<tr>
+						<td>dcterms:title</td>
+						<td>rdf:XMLLiteral</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 element.</td>
+					</tr>
+				</tbody>
+			</table>
+
+			<p>
+				The predicate
+				<code>dcterms:type</code>
+				should not be used, instead use
+				<code>rdf:type</code>
+				. [<cite><a href="#bib-DC-RDF" class="bibref">DC-RDF</a></cite>].
+			</p>
+
+			<p>
+				<strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
+			</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>Property</th>
+						<th>Range/DataType</th>
+						<th>Comment</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td>rdf:type</td>
+						<td>rdfs:Class</td>
+						<td>The type or types of the resource</td>
+					</tr>
+				</tbody>
+			</table>
+
+			<p>
+				<strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
+			</p>
+
+			<table class="simple">
+				<thead>
+					<tr>
+						<th>Property</th>
+						<th>Range/DataType</th>
+						<th>Comment</th>
+					</tr>
+				</thead>
+				<tbody>
+					<tr>
+						<td>rdfs:member</td>
+						<td>rdfs:Resource</td>
+						<td>&nbsp;</td>
+					</tr>
+					<tr>
+						<td>rdfs:label</td>
+						<td>rdfs:Literal</td>
+						<td>Only use this in vocabulary documents, to define the name
+							of the vocabulary term.</td>
+					</tr>
+				</tbody>
+			</table>
+
+
+
+		</section>
+
+
+		<section id="use-qvalues-properly">
+			<h3 id="h3_use-qvalues-properly" role="heading" aria-level="2"><span class="secno">2.10 </span>Use qvalues properly</h3>
+
+			<p>Quality factors allow the user or user agent to indicate the
+				relative degree of preference for a media-range, using the qvalue
+				scale from 0 to 1. The default value is q=1. Take the following for
+				example:</p>
+
+			<p>
+				<code>Accept: text/turtle; q=0.5, application/json</code>
+			</p>
+
+			<p>This should be interpreted as "I prefer application/json, but
+				send me text/turtle if it is the best available after a 50%
+				mark-down in quality."</p>
+
+			<p>Improper handling of qvalues is a common problem in
+				implementations of content negotiation.
+			</p><p>Refer to Section 14, Header Field Definitions, in the
+				[<cite><a href="#bib-HTTP11" class="bibref">HTTP11</a></cite>] specification to understand the proper use and evaluation
+				of qvalues for both client and server implementations.</p>
+
+		</section>
+
+		<section id="respond-with-primary-urls-and-use-them-for-identity-comparison">
+			<h3 id="h3_respond-with-primary-urls-and-use-them-for-identity-comparison" role="heading" aria-level="2"><span class="secno">2.11 </span>Respond with primary URLs and use them for identity comparison</h3>
+
+			<p>Clients can access an LDPR using multiple URLs. An LDP server
+				should respond to each of those requests using a single consistent
+				URL, a primary URL, for the LDPR. This primary URL may be found
+				in the response's Location and/or Content-Location headers, and
+				potentially also in the representation of the LDPR. A common case is
+				URLs that vary by protocol, one HTTP and one HTTPS, but are
+				otherwise identical. In most cases those two URLs refer to the same
+				resource, and the server should respond to requests on either URL
+				with a single (primary) URL.</p>
+
+			<p>Clients should use the primary URL as an LDPR's identity;
+				for example, when determining if two URLs refer to the same resource
+				clients should compare the primary URLs, not the URLs used to
+				access the resources.  Note that this usage <em>does</em> imply that the
+				client has sufficient reason to trust the headers and/or content
+				by which the primary URL is communicated to the client, which is 
+				beyond what HTTP alone can guarantee [<cite><a href="#bib-RFC7231" class="bibref">RFC7231</a></cite>].
+				</p>
+
+		</section>
+
+		<section id="representing-relationships-between-resources">
+			<h3 id="h3_representing-relationships-between-resources" role="heading" aria-level="2"><span class="secno">2.12 </span>Representing relationships between resources</h3>
+			<p>LDPRs can use one RDF triple to represent a link
+				(relationship) to another resource. Having the source resource’s URI
+				as the subject and the target resource’s URI as the object of the
+				triple is enough. Contrary to a misconception that readers with
+				certain backgrounds may assume, the creation of an
+				"intermediate link" resource is not required to express
+				the relationship.</p>
+		</section>
+
+		<section id="minimize-server-specific-constraints">
+			<h3 id="h3_minimize-server-specific-constraints" role="heading" aria-level="2"><span class="secno">2.13 </span>Minimize server-specific constraints</h3>
+			<p>LDP servers should enable simple creation and modification of
+				LDPRs.</p>
+
+			<p>It may be common for LDP servers to put restrictions on
+				representations – for example, the range of rdf:type predicates,
+				datatypes of the objects of predicates, and the number of
+				occurrences of predicates in an LDPR, but servers should minimize
+				such restrictions.</p>
+
+			<p>For some server applications, excessive constraints on
+				modification of resources may be required. However, enforcement of
+				more complex constraints will greatly restrict the set of clients
+				that can modify resources. For interoperability with a wider range
+				of clients, implementers are therefore encouraged to minimize
+				server-specific constraints.</p>
+		</section>
+
+	</section>
+	<!-- End Best Practices Section -->
+
+	<section id="guidelines">
+
+		<!--OddPage--><h2 id="h2_guidelines" role="heading" aria-level="1"><span class="secno">3. </span>Guidelines</h2>
+
+		<section id="containers-are-not-limited-to-membership-and-containment-triples">
+
+			<h3 id="h3_containers-are-not-limited-to-membership-and-containment-triples" role="heading" aria-level="2"><span class="secno">3.1 </span>Containers are not limited to membership and containment triples</h3>
+
+			<p>It is important to remember that a Linked Data Platform
+				Container (LDPC) is also a Linked Data Platform RDF Source (LDP-RS) and
+				though it might exist as a membership controller, it may also represent 
+				additional data that is valuable to the agents that access
+				it.</p>
+
+		</section>
+
+		<section id="finding-established-vocabularies">
+			<h3 id="h3_finding-established-vocabularies" role="heading" aria-level="2"><span class="secno">3.2 </span>Finding established vocabularies</h3>
+
+			<p>Following are some useful resources for finding and leveraging
+				pre-existing, common, and well-established vocabularies.</p>
+
+
+			<ul>
+				<li><strong>Linked Open Vocabularies (LOV)</strong> 
+					[<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>] - an entry point to the growing
+				ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
+				in the Linked Data Cloud. Users can find vocabularies listed and
+				individually described by metadata, classified by vocabulary spaces,
+				and interlinked using the dedicated vocabulary VOAF. The site allows
+				users to query the LOV dataset either at vocabulary level or at
+				element level, exploring the vocabulary content using full-text
+				faceted search, and finding metrics about the use of vocabularies in
+				the Semantic Web. Users can also suggest a new vocabulary to add to
+				LOV. [<cite><a href="#bib-LOV" class="bibref">LOV</a></cite>]</li>
+				<li><strong>Common Vocabularies / Ontologies / Micromodels</strong> [<cite><a href="#bib-LOD-COMMON-VOCABS" class="bibref">LOD-COMMON-VOCABS</a></cite>] - a wiki list maintained by the Linked Data LOD community project.</li>
+			</ul>
+
+			<div style="clear: both"></div>
+
+		</section>
+
+	</section>
+	<!-- End Guidelines Section -->
+
+	<section id="acknowledgements" class="appendix">
+		<!--OddPage--><h2 id="h2_acknowledgements" role="heading" aria-level="1"><span class="secno">A. </span>Acknowledgements</h2>
+		<p>Many thanks to Robin Berjon and all contributors to the <a href="http://www.w3.org/respec/">ReSpec</a> tool, which makes writing these kinds of documents much easier.
+		</p>
+		<p>To the following individuals who, in addition to the editors, have 
+contributed either directly or indirectly to the ongoing improvement of 
+this document: 
+			</p><ul>
+				<li><a href="http://lehors.wordpress.com/">Arnaud Le Hors</a>, IBM</li>
+				<li><a href="http://www.linkedin.com/pub/ashok-malhotra/4/675/6a2">Ashok Malhotra</a>, Oracle</li>
+				<li>Bart van Leeuwen</li>
+				<li>David Wood</li>
+				<li><a href="http://www.w3.org/People/Eric/">Eric Prud'hommeaux</a>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
+				<li>Henry Story</li>
+				<li>John Arwe, IBM</li>
+				<li>Kevin Page</li>
+				<li>Miel Vander Sande</li>
+				<li><a href="http://melvincarvalho.com/">Melvin Carvalho</a></li>
+				<li>Raúl García Castro</li>
+				<li><a href="http://richard.cyganiak.de/">Richard Cyganiak</a></li>
+				<li><a href="http://www.linkedin.com/in/yadnem">Roger Menday</a>, Fujitsu Laboratories of Europe</li>
+				<li><a href="http://www.w3.org/People/Sandro/">Sandro Hawke</a>, <abbr title="World Wide Web Consortium">W3C</abbr></li>
+				<li><a href="http://stevebattle.me/">Steve Battle</a></li>
+				<li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
+				<li>Ted Thibodeau</li>
+			</ul>
+	</section>
+
+
+
+
+
+<div style="position: fixed; top: 20px; right: 20px; width: 202px; text-align: right;" id="respec-ui" class="removeOnSave"><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); font-weight: bold; border: 1px solid rgb(204, 204, 204); border-radius: 5px;">ReSpec</button><div style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border: 1px solid rgb(0, 0, 0); width: 200px; display: none; text-align: left; margin-top: 5px; margin-right: 5px;"><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">Save Snapshot</button><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">About ReSpec</button><button style="background: none repeat scroll 0% 0% rgb(255, 255, 255); border-width: medium medium 1px; border-style: none none solid; border-color: -moz-use-text-color -moz-use-text-color rgb(204, 204, 204); -moz-border-top-colors: none; -moz-border-right-colors: none; -moz-border-bottom-colors: none; -moz-border-left-colors: none; border-image: none; width: 100%; text-align: left; font-size: inherit;">Search Specref DB</button></div></div><section rel="bibo:Chapter" resource="#references" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 id="h2_references" role="heading" aria-level="1"><span class="secno">B. </span>References</h2><section rel="bibo:Chapter" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3 id="h3_informative-references" role="heading" aria-level="2"><span class="secno">B.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-DC-RDF">[DC-RDF]</dt><dd rel="dcterms:references">M. Nilsson et al. <a href="http://dublincore.org/documents/dc-rdf/"><cite>Expressing Dublin Core metadata using the Resource Description Framework (RDF)</cite></a>. 14 January 2008. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/dc-rdf/">http://dublincore.org/documents/dc-rdf/</a>
+</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7230.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7230.txt">http://www.ietf.org/rfc/rfc7230.txt</a>
+</dd><dt id="bib-LD-DI">[LD-DI]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data - Design Issues</cite></a>. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+</dd><dt id="bib-LD-GLOSSARY">[LD-GLOSSARY]</dt><dd rel="dcterms:references">B Hyland; G Atemezing; M Pendleton; B Srivastava. <a href="http://www.w3.org/TR/ld-glossary/"><cite>Linked Data Glossary</cite></a>. URL: <a href="http://www.w3.org/TR/ld-glossary/">http://www.w3.org/TR/ld-glossary/</a>
+</dd><dt id="bib-LDP">[LDP]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 19 June 2014. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-LDP-PRIMER">[LDP-PRIMER]</dt><dd rel="dcterms:references">Nandana Mihindukulasooriya; Roger Menday. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html"><cite>Linked Data Platforn Primer</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-primer/ldp-primer.html</a>
+</dd><dt id="bib-LDP-TESTS">[LDP-TESTS]</dt><dd rel="dcterms:references">Raúl García-Castro. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. W3C Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html</a>
+</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
+</dd><dt id="bib-LOD-COMMON-VOCABS">[LOD-COMMON-VOCABS]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"><cite>Common Vocabularies / Ontologies / Micromodels </cite></a>. URL: <a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies">http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies</a>
+</dd><dt id="bib-LOV">[LOV]</dt><dd rel="dcterms:references"><a href="http://lov.okfn.org/dataset/lov/"><cite>Linked Open Vocabularies (LOV)</cite></a>. URL: <a href="http://lov.okfn.org/dataset/lov/">http://lov.okfn.org/dataset/lov/</a>
+</dd><dt id="bib-RDF-PRIMER11">[RDF-PRIMER11]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/"><cite>RDF 1.1 Primer</cite></a>. W3C Working Group Note. URL: <a href="http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/">http://www.w3.org/TR/2014/NOTE-rdf11-primer-20140225/</a>
+</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:references">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema/"><cite>RDF Schema 1.1</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</a>
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax</cite></a>. January 2005. Internet Standard. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
+</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:references">M. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:references">R. Fielding, Ed.; J. Reschke, Ed.. <a href="http://www.ietf.org/rfc/rfc7231.txt"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. June 2014. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc7231.txt">http://www.ietf.org/rfc/rfc7231.txt</a>
+</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 25 February 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-XMLSCHEMA11-2">[XMLSCHEMA11-2]</dt><dd rel="dcterms:references">David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al. <a href="http://www.w3.org/TR/xmlschema11-2/"><cite>W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes</cite></a>. 5 April 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/xmlschema11-2/">http://www.w3.org/TR/xmlschema11-2/</a>
+</dd><dt id="bib-metaDataInURI">[metaDataInURI]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31"><cite>The use of Metadata in URIs</cite></a>. finding. URL: <a href="http://www.w3.org/2001/tag/doc/metaDataInURI-31">http://www.w3.org/2001/tag/doc/metaDataInURI-31</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file