--- a/TR/NOTE-ldp-bp-20140829/Overview.html Tue Aug 26 18:19:31 2014 -0700
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1215 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" dir="ltr" typeof="bibo:Document w3p:NOTE" about="" property="dcterms:language" content="en">
-<head>
-<title>Linked Data Platform Best Practices and Guidelines</title>
-<!-- Changed by: , 25-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-29-august-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-08-29T07: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">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/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> </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