--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/NOTE-ldp-bp-20140828/Overview.html Tue Aug 26 18:19:31 2014 -0700
@@ -0,0 +1,1215 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en">
+<head>
+<title>Linked Data Platform Best Practices and Guidelines</title>
+<!-- Changed by: , 26-Aug-2014 -->
+<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 href="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[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 src="https://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></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-28-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-28T07:00:00.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-08-28">28 August 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-bp-20140828/">http://www.w3.org/TR/2014/NOTE-ldp-bp-20140828/</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: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix contact: <http://www.w3.org/2000/10/swap/pim/contact#>.
+
+<http://www.w3.org/People/EM/contact#me>
+ a contact:Person;
+ contact:fullName "Eric Miller";
+ contact:mailbox <mailto:em@w3.org>;
+ 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><http://www.w3.org/1999/02/22-rdf-syntax-ns#type> 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: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1/>
+ a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains
+ <http://example.org/container1/member1>,
+ <http://example.org/container1/member2>,
+ <http://example.org/container1/member3>.</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: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <member1>, <member2>, <member3> .</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: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1>
+ a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains
+ <http://example.org/container1/member1>,
+ <http://example.org/container1/member2>,
+ <http://example.org/container1/member3>.</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: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <member1>, <member2>, <member3> .</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: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1>
+ a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains
+ <http://example.org/member1>,
+ <http://example.org/member2>,
+ <http://example.org/member3>.</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: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <container1/member1>, <container1/member2>, <container1/member3> .</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><#foo></code>
+ ,
+ <code><#bar></code>
+ and
+ <code><#baz></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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2004/REC-xmlschema-2-20041028/#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/TR/2014/REC-rdf11-concepts-20140225/#section-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> </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>
+
+
+
+
+
+<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