--- a/ldp-bp/ldp-bp.html Sun Jul 14 22:45:26 2013 -0400
+++ b/ldp-bp/ldp-bp.html Sun Jul 14 22:46:34 2013 -0400
@@ -104,589 +104,618 @@
return '<span style="background-color:#ccffcc">' + content + '</span>';
}
</script>
+
+
</head>
<body>
- <section id='abstract'>This document provides best practices
- and general guidelines for Implementing Linked Data Platform servers,
- clients and related systems.</section>
-
- <section>
-
- <h2>About this Document</h2>
-
- <section>
-
- <h3>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 <a
- href="http://www.w3.org/2012/ldp/wiki/Primer">LDP Primer</a>, was
- therefore developed to provide additional context. Drawing upon the
- professional experiences of its authors and contributors, research
- into the rich history of all related technologies, and continuous
- feedback from the community at large, it aims to help system
- implementers:
- </p>
- <ul>
- <li>avoid common pitfalls,</li>
- <li>improve quality,</li>
- <li>improve development and maintenance efficiency, and</li>
- <li>achieve greater interoperability with LDP’s within the
- enterprise, between enterprises, and across the World Wide Web.</li>
- </ul>
- </section>
-
- <section>
-
- <h3>Terminology</h3>
-
- <p>For the purposes of this document, we have found it useful to
- make a minor, yet important distinction between the term 'best
- practice' and the term 'guideline'. For the purposes of this
- document, we define and differentiate the terms as such:</p>
-
- <dl>
- <dt>best practice</dt>
- <dd>A good 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 one should
- implement technology (i.e. LDP servers, clients, and related
- systems). In this document, the best practices might be used as a
- kind of check-list against which one 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 your knowledge and
- understanding and help you achieve a result, but that may not be
- directly applicable to your implementation or recognized by
- consensus as the 'best' method or technique.</dd>
- </dl>
-
- <p>
- Please see the <a
- href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#terms">Terminology
- section of the LDP specification</a> as well as the <a
- href="http://www.w3.org/TR/ld-glossary/">Linked Data Glossary</a>
- for definitions to a variety of terms used in this document and
- related to the Linked Data sphere of knowledge.
- </p>
-
- </section>
-
- <section>
-
- <h3>Prerequisites and Assumptions</h3>
- <p class="note">TO DO: Consider inserting some prereqs and
- assumptions here that help to clarify the audience, level of
- understanding expected from that audience. Perhaps, provide an
- example learning path for the uninitiated.</p>
-
- <h4>Additional References and Resources</h4>
-
- <p>
- Implementers should have at least a general familiarity with the <a
- href="#informative-references">informative references</a> cited in
- this document. Additionally, implementers should familiarize
- themselves with the following references, which can be useful study
- and working references.
- <dl class="bibliography">
-
- <dt><a name="ldDesignIssues"></a>Linked Data - Design Issues</dt>
- <dd>Tim Berners-Lee's (2006-07-27) document, which originated
- "the four rules" of Linked Data, which outline the key
- principles behind Linked Data for the World Wide Web.<br />
- URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+ <section id='abstract'>
+ This document provides best practices and general guidelines for Implementing
+ Linked Data Platform servers, clients and related systems.
+ </section>
+
+ <section>
+
+ <h2>About this Document</h2>
+
+ <section>
+
+ <h3>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 <a
+ href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html">LDP Primer</a>, was
+ therefore developed to provide additional context. Drawing upon the
+ professional experiences of its authors and contributors, research
+ into the rich history of all related technologies, and continuous
+ feedback from the community at large, it aims to help system
+ implementers:
+ </p>
+ <ul>
+ <li>avoid common pitfalls,</li>
+ <li>improve quality,</li>
+ <li>improve development and maintenance efficiency, and</li>
+ <li>achieve greater interoperability with LDP’s within the
+ enterprise, between enterprises, and across the World Wide Web.</li>
+ </ul>
+ </section>
+
+ <section>
+
+ <h3>Terminology</h3>
+
+ <p>For the purposes of this document, we have found it useful to
+ make a minor, yet important distinction between the term 'best
+ practice' and the term 'guideline'. For the purposes of this
+ document, we define and differentiate the terms as such:</p>
+
+ <dl>
+ <dt>best practice</dt>
+ <dd>A good 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 one should
+ implement technology (i.e. LDP servers, clients, and related
+ systems). In this document, the best practices might be used as a
+ kind of check-list against which one 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 your knowledge and
+ understanding, but that may not be directly applicable to your implementation
+ or recognized by consensus as the 'best' method or technique.</dd>
+ </dl>
+
+ <p>
+ Please see the <a
+ href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#terms">Terminology
+ section of the LDP specification</a> as well as the <a
+ href="http://www.w3.org/TR/ld-glossary/">Linked Data Glossary</a>
+ for definitions to a variety of terms used in this document and
+ related to the Linked Data sphere of knowledge.
+ </p>
+
+ </section>
+
+ <section>
+
+ <h3>Prerequisites and Assumptions</h3>
+
+ <p class="note">TO DO: Consider inserting some prereqs and
+ assumptions here that help to clarify the audience, level of
+ understanding expected from that audience. Perhaps, provide an
+ example learning path for the uninitiated.</p>
+
+ <h4>Additional References and Resources</h4>
+
+ <p>
+ Implementers should have at least a general familiarity with the <a
+ href="#informative-references">informative references</a> cited in
+ this document. Additionally, implementers should familiarize
+ themselves with the following references, which can be useful study
+ and working references.
+ <dl class="bibliography">
+
+ <dt><a name="ldDesignIssues"></a>Linked Data - Design Issues</dt>
+ <dd>Tim Berners-Lee's (2006-07-27) document, which originated
+ "the four rules" of Linked Data, which outline the key
+ principles behind Linked Data for the World Wide Web.<br />
+ URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+ </dd>
+
+ <dt>Linked Data Glossary</dt>
+ <dd>
+ <span data-transform='highlight'>INSERT BYLINE</span><br /> 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.<br /> W3C Working Group
+ Note, 27 June 2013<br /> URL: <a href="">http://www.w3.org/TR/ld-glossary/</a>
</dd>
-
- <dt>Linked Data Glossary</dt>
- <dd>
- <span data-transform='highlight'>INSERT BYLINE</span><br /> 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.<br /> W3C Working Group
- Note, 27 June 2013<br /> URL: <a href="">http://www.w3.org/TR/ld-glossary/</a>
- </dd>
- <dt>Linked Data Platform 1.0 Test Cases</dt>
- <dd>
- R García-Castro, et al. <span data-transform='highlight'>dd
- Month yyyy</span>.<br /> <span data-transform='highlight'>INSERT
- DOCUMENT ABSTRACT</span><br /> <span data-transform='highlight'>INSERT
- W3C DOCUMENT TYPE</span><br /> URL: <a
- href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html</a>
- </dd>
- <dt>Linked Data Platform Primer</dt>
- <dd>
- <span data-transform='highlight'>INSERT BYLINE</span><br /> <span
- data-transform='highlight'>INSERT DOCUMENT ABSTRACT</span><br /> <span
- data-transform='highlight'>INSERT W3C DOCUMENT TYPE</span><br />
- URL: <a href="http://www.w3.org/2012/ldp/wiki/Primer">http://www.w3.org/2012/ldp/wiki/Primer</a><br />
- and the new editor's working draft:<br /> URL: <a
- href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html</a>
- </dd>
- </dl>
-
-
-
- </section>
-
- <section>
-
- <h2>Best Practices</h2>
-
- <section>
-
- <h3>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 in his 2006 publication, <a
- href="http://www.w3.org/DesignIssues/LinkedData.html">Linked
- Data - Design Issues</a>. It is therefore ideal that predicate URIs
- identify LDPRs with representations that are retrievable. LDP
- servers should at least provide [[RDF-SCHEMA]] representations of
- these predicates where possible.
- </p>
-
- <p>Of course, it is also a common practice to reuse properties
- from vocabularies that you don't own. In this case, you typically
- 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
- standard as a benchmark for which to judge the efficacy of a
- vocabulary's use for linking data.</p>
+ <dt>Linked Data Platform 1.0 Test Cases</dt>
+ <dd>
+ R García-Castro, et al. <span data-transform='highlight'>dd
+ Month yyyy</span>.<br /> <span data-transform='highlight'>INSERT
+ DOCUMENT ABSTRACT</span><br /> <span data-transform='highlight'>INSERT
+ W3C DOCUMENT TYPE</span><br /> URL: <a
+ href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html</a>
+ </dd>
+ <dt>Linked Data Platform Primer</dt>
+ <dd>
+ <span data-transform='highlight'>INSERT BYLINE</span><br /> <span
+ data-transform='highlight'>INSERT DOCUMENT ABSTRACT</span><br /> <span
+ data-transform='highlight'>INSERT W3C DOCUMENT TYPE</span><br />
+ URL: <a href="http://www.w3.org/2012/ldp/wiki/Primer">http://www.w3.org/2012/ldp/wiki/Primer</a><br />
+ and the new editor's working draft:<br /> URL: <a
+ href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html</a>
+ </dd>
+ </dl>
</section>
-
- <section>
-
- <h3>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 your data more useful in the broadest
- context, you should explicitly define the type when possible and
- appropriate and you should use the
- <code>rdf:type</code>
- predicate defined by [[RDF-SCHEMA]] when doing so.
- </p>
-
- <p>This provides a way for clients to easily determine the type
- 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>
-
- <pre title="Turtle with explicit declaration of rdf:type"
- class='example' data-include='include-rdf-type.ttl'
- data-oninclude='fixCode'></pre>
-
- </section>
-
- <section>
-
- <h3>Use relative URIs</h3>
-
- <p class="note">
- See <a href="http://www.w3.org/2012/ldp/track/issues/29">ldp-ISSUE-29</a>
- (Relative URIs)
- </p>
+
+ </section>
+
+ <section>
+
+ <h2>Best Practices</h2>
+
+ <section>
+
+ <h3>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 in his 2006 publication, <a
+ href="http://www.w3.org/DesignIssues/LinkedData.html">Linked
+ Data - Design Issues</a>. It is therefore ideal that predicate URIs
+ identify LDPRs with representations that are retrievable. LDP
+ servers should at least provide [[RDF-SCHEMA]] representations of
+ these predicates where possible.
+ </p>
+
+ <p>Of course, it is also a common practice to reuse properties
+ from vocabularies that you don't own. In this case, you typically
+ 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
+ standard as a benchmark for which to judge the efficacy of a
+ vocabulary's use for linking data.</p>
+
+ </section>
+
+ <section>
+
+ <h3>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 your data more useful in the broadest
+ context, you should explicitly define the type when possible and
+ appropriate and you should use the
+ <code>rdf:type</code>
+ predicate defined by [[RDF-SCHEMA]] when doing so.
+ </p>
+
+ <p>This provides a way for clients to easily determine the type
+ 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>
+
+ <pre title="Turtle with explicit declaration of rdf:type"
+ class='example' data-include='include-rdf-type.ttl'
+ data-oninclude='fixCode'></pre>
+
+ </section>
+
+ <section>
+
+ <h3>Use relative URIs</h3>
+
+ <!-- http://www.w3.org/2012/ldp/track/issues/29 -->
- <p>Relative URIs are</p>
- <ul>
- <li>crucial in creation of resources as the client cannot know
- what the name of the to be created resource is going to be</li>
- <li>relative URIs are helpful on the server:
- <ul>
- <li>they allow editing of information on the file system to
- closely match the results from the web server. This makes it
- possible to debug without needing the server to be running</li>
- <li>mappings from OO or SQL to RDF need not be encumbered
- with information about the name of the server, which may only be
- available at a much later point.</li>
- </ul>
- </li>
- </ul>
-
- </section>
-
- <section>
- <h3>Represent container membership with hierarchical URIs</h3>
- <p>Hierarchical URIs are good for containers because they enable
- relativizing.</p>
- </section>
+ <p>Relative URIs are useful to the Linked Data Platform in much the same ways that
+ relative URLs [[RFC1808]] have been useful to traditional web systems. Since the things
+ referred to by Linked Data URIs should ideally provide a retrievable representation, 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 Container model of the LDP promotes hierarchical representations.</p>
- <section>
- <h3>Use fragments as entity identifiers</h3>
-
-
- <p>Fragments are nice because they can be expressed as relative
- URIs on the document describing them.</p>
- </section>
-
-
- <section>
- <h3>Prefer standard datatypes</h3>
+ <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>
- <p class="note">
- This was originally part of <a
- href="http://www.w3.org/TR/2012/WD-ldp-20121025/#general">old
- Section 4.1.9</a> that was deleted from the FPWD based on resolution
- of <a href="https://www.w3.org/2012/ldp/track/issues/6">ISSUE-6</a>.
- </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>
-
- <p>LDPR representations must use only the following standard
- datatypes. RDF does not by itself define datatypes to be used for
- literal property values, therefore a set of standard datatypes
- based on [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] are to be used:</p>
+ <pre title="Turtle RDF representation of http://example.org/container1/ with absolute URIs"
+ class='example' data-include='rdf-absolute-uris.ttl'
+ data-oninclude='fixCode'></pre>
- <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#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>
+ <pre title="Turtle RDF representation of http://example.org/container1/ with relative URIs"
+ class='example' data-include='rdf-relative-uris.ttl'
+ data-oninclude='fixCode'></pre>
+ </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 ommited, there can be less information to modify when that
+ information changes. This can make moving resources to new servers or to a new position in a containment hierarchy easier.</dd>
+
+ <dt>Relative URIs are convenient during development.</dt>
+ <dd>During development the scheme and network location information in a URI may either be unkown 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 ommiting 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 the server isn't running.</dd>
+
+ <dt>Relative URIs are convenient during development.</dt>
+ <dd>During development the scheme and network location information in a URI may either be unkown 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 ommiting this information.</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>
+ <h3>Represent container membership with hierarchical URIs</h3>
+ <p>Hierarchical URIs are good for containers because they enable
+ relativizing.</p>
+ <p>Don't forget the corrorlary to this, which Henry noted and that should probably go in this guide: <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html">http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html</a></p>
+ </section>
+
+ <section>
+ <h3>Use fragments as entity identifiers</h3>
+
+
+ <p>Fragments are nice because they can be expressed as relative
+ URIs on the document describing them.</p>
+ </section>
+
+
+ <section>
+ <h3>Prefer standard datatypes</h3>
+
+ <p class="note">
+ This was originally part of <a
+ href="http://www.w3.org/TR/2012/WD-ldp-20121025/#general">old
+ Section 4.1.9</a> that was deleted from the FPWD based on resolution
+ of <a href="https://www.w3.org/2012/ldp/track/issues/6">ISSUE-6</a>.
+ </p>
+
+
+ <p>LDPR representations must use only the following standard
+ datatypes. RDF does not by itself define datatypes to be used for
+ literal property values, therefore a set of standard datatypes
+ based on [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] are to 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#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>
+ <h3>Re-use established linked data vocabularies instead of
+ (re-)inventing duplicates</h3>
+
+ <p class="note">
+ This was originally from <a
+ href="http://www.w3.org/TR/2012/WD-ldp-20121025/#common-properties">old
+ section 4.8</a> that was deleted from the FPWD based on resolution of
+ <a href="https://www.w3.org/2012/ldp/track/issues/42">ISSUE-42</a>.
+ As indicated in that issue, the text below (which was simply copied
+ from the spec) may need further editing.
+ </p>
+
+ <p>Common Properties</p>
+
+ <p>This section summarizes some well-known RDF vocabularies that
+ must 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 BP resource has a description, and the application
+ semantic of that description is compatible with
+ dcterms:description, then dcterms:description must be used. If
+ needed, additional application-specific predicates may be used. A
+ specification for a domain that is based on BP may require one or
+ more of these properties for a particular resource type. The Range
+ column in the tables below identify the recommended rdfs:range for
+ the properties.</p>
+
+ <p>
+ From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>
+ </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>
+ . [[DC-RDF]].
+ </p>
+
+ <p>
+ 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>
+ </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>
+ From RDF Schema URI: <a
+ href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a>
+ </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>
+ <h3>Properly use q values</h3>
+ <p>Not properly handling q values is a major problem in
+ implementations of content negotiation.</p>
+ </section>
+
+ <section>
+ <h3>Use canonical URIs for identity comparison</h3>
+ <ul>
+
+ <li>Location and/or Content-Location header contains canonical
+ URI</li>
+ <li>Clients should use canonical URI when comparing resources
+ for "same-ness" (identity), even if the resources are accessed via
+ distinct URLs.</li>
+ <li>Most 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 to either URL with a single (canonical) URL.</li>
+ </ul>
+ </section>
+
+
+ <section>
+ <h3>Servers should serve up canonical URLs</h3>
+ <p>This was removed from the spec:</p>
+ <blockquote>4.1.4 Clients can access an LDPR using
+ multiple URLs, for example when DNS aliasing is used. An LDPR
+ server must respond to each of those requests using a single
+ consistent URL, a canonical URL, for the LDPR which may be found in
+ the response's Location header and potentially also in the
+ representation of the LDPR. Clients should use the canonical URL as
+ an LDPR's identity; for example, when determining if two URLs refer
+ to the same resource clients need to compare the canonical URLs not
+ the URLs used to access the resources.</blockquote>
+
+ <p>
+ As part of the discussion around <a
+ href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a> it
+ was seen as most likely this should be implementation guidance.
+ </p>
+ </section>
+
+ <section>
+ <h3>Representing relationships between resources</h3>
+ <p>This was removed from the spec:</p>
+ <blockquote>4.1.9 LDPRs must use at least one RDF
+ triple to represent a link (relationship) to another resource. In
+ other words, having the source resource’s URI as the subject and
+ the target resource’s URI as the object of the triple representing
+ the link (relationship) is enough and does not require the creation
+ of an intermediate link resource to describe the relationship.</blockquote>
+ <p>This addresses a misconception that the editors observed.
+ Readers with certain background assume that one always needs a
+ “link resource” to express a relationship.</p>
+
+ </section>
+
+
+
+ </section>
+
+ <section>
+
+ <h2>Guidelines</h2>
+
+ <section>
+
+ <h3>Containers are not limited to same-subject, same-predicate
+ triples</h3>
+
+ <p>
+ The LDP specification defines a Container as "a Linked Data
+ Platform Resource (LDPR) representing a collection of same-subject,
+ same-predicate triples." This can easily be misconstrued to
+ mean that a Container should <em>only</em> contain same-subject,
+ same-predicate triples. While Containers <em>may</em> contain only
+ same-subject, same-predicate triples (i.e. the membership subjects
+ and membership predicates of its membership triples), it is free to
+ contain others. The definition is meant to clarify only those
+ attributes that are directly relavant to the interaction model of a
+ Container, but not to limit them to those attributes alone.
+ </p>
+
+ <p>It is important to remember that a Linked Data Platform
+ Container (LDPC) is also a Linked Data Platform Resource (LDPR) 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>
+ <h3>Guideline 2</h3>
+ <p>Eplurbis unum...</p>
+ </section>
+ -->
+ </section>
+
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p>Many thanks to Robin Berjon for making our lives so much
+ easier with his cool tool.</p>
</section>
-
- <section>
- <h3>Re-use established linked data vocabularies instead of
- (re-)inventing duplicates</h3>
-
- <p class="note">
- This was originally from <a
- href="http://www.w3.org/TR/2012/WD-ldp-20121025/#common-properties">old
- section 4.8</a> that was deleted from the FPWD based on resolution of
- <a href="https://www.w3.org/2012/ldp/track/issues/42">ISSUE-42</a>.
- As indicated in that issue, the text below (which was simply copied
- from the spec) may need further editing.
- </p>
-
- <p>Common Properties</p>
-
- <p>This section summarizes some well-known RDF vocabularies that
- must 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 BP resource has a description, and the application
- semantic of that description is compatible with
- dcterms:description, then dcterms:description must be used. If
- needed, additional application-specific predicates may be used. A
- specification for a domain that is based on BP may require one or
- more of these properties for a particular resource type. The Range
- column in the tables below identify the recommended rdfs:range for
- the properties.</p>
-
- <p>
- From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>
- </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>
- . [[DC-RDF]].
- </p>
-
- <p>
- 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>
- </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>
- From RDF Schema URI: <a
- href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a>
- </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>
- <h3>Properly use q values</h3>
- <p>Not properly handling q values is a major problem in
- implementations of content negotiation.</p>
- </section>
-
- <section>
- <h3>Use canonical URIs for identity comparison</h3>
- <ul>
-
- <li>Location and/or Content-Location header contains canonical
- URI</li>
- <li>Clients should use canonical URI when comparing resources
- for "same-ness" (identity), even if the resources are accessed via
- distinct URLs.</li>
- <li>Most 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 to either URL with a single (canonical) URL.</li>
- </ul>
- </section>
-
-
- <section>
- <h3>Servers should serve up canonical URLs</h3>
- <p>This was removed from the spec:</p>
- <blockquote>4.1.4 Clients can access an LDPR using
- multiple URLs, for example when DNS aliasing is used. An LDPR
- server must respond to each of those requests using a single
- consistent URL, a canonical URL, for the LDPR which may be found in
- the response's Location header and potentially also in the
- representation of the LDPR. Clients should use the canonical URL as
- an LDPR's identity; for example, when determining if two URLs refer
- to the same resource clients need to compare the canonical URLs not
- the URLs used to access the resources.</blockquote>
-
- <p>
- As part of the discussion around <a
- href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a> it
- was seen as most likely this should be implementation guidance.
- </p>
- </section>
-
- <section>
- <h3>Representing relationships between resources</h3>
- <p>This was removed from the spec:</p>
- <blockquote>4.1.9 LDPRs must use at least one RDF
- triple to represent a link (relationship) to another resource. In
- other words, having the source resource’s URI as the subject and
- the target resource’s URI as the object of the triple representing
- the link (relationship) is enough and does not require the creation
- of an intermediate link resource to describe the relationship.</blockquote>
- <p>This addresses a misconception that the editors observed.
- Readers with certain background assume that one always needs a
- “link resource” to express a relationship.</p>
-
- </section>
-
-
-
- </section>
-
- <section>
-
- <h2>Guidelines</h2>
-
- <section>
-
- <h3>Containers are not limited to same-subject, same-predicate
- triples</h3>
-
- <p>
- The LDP specification defines a Container as "a Linked Data
- Platform Resource (LDPR) representing a collection of same-subject,
- same-predicate triples." This can easily be misconstrued to
- mean that a Container should <em>only</em> contain same-subject,
- same-predicate triples. While Containers <em>may</em> contain only
- same-subject, same-predicate triples (i.e. the membership subjects
- and membership predicates of its membership triples), it is free to
- contain others. The definition is meant to clarify only those
- attributes that are directly relavant to the interaction model of a
- Container, but not to limit them to those attributes alone.
- </p>
-
- <p>It is important to remember that a Linked Data Platform
- Container (LDPC) is also a Linked Data Platform Resource (LDPR) 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>
- <h3>Guideline 2</h3>
- <p>Eplurbis unum...</p>
- </section>
- -->
- </section>
-
-
-
- <section class='appendix'>
- <h2>Acknowledgements</h2>
- <p>Many thanks to Robin Berjon for making our lives so much
- easier with his cool tool.</p>
- </section>
+
</body>
</html>