--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-bp/ldp-bp.html Mon Jul 01 15:38:31 2013 -0500
@@ -0,0 +1,484 @@
+<!DOCTYPE html>
+<html>
+<head>
+<title>LDP Best Practices</title>
+<meta http-equiv='Content-Type' content='text/html;charset=utf-8' />
+<!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+<!-- script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script -->
+<script src='http://www.w3.org/Tools/respec/respec-w3c-common'
+ class='remove' async></script>
+<script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus : "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName : "ldp-bp",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "Guidelines for Implementing Linked Data Platform Servers, Clients and Related Systems",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ // edDraftURI: "http://dev.w3.org/2009/dap/ReSpec.js/documentation.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS : [ "http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css" ],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors : [
+ {
+ name : "Cody Burleson",
+ url : "http://codyburleson.com/",
+ company : "Base22",
+ companyURL : "http://base22.com/"
+ },
+ {
+ name : "Nandana Mihindukulasooriya",
+ url : "http://www.nandana.org/",
+ company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
+ companyURL : "http://www.oeg-upm.net/"
+ } ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg : "Linked Data Platform Working Group",
+
+ // URI of the public WG page
+ wgURI : "http://www.w3.org/2012/ldp/wiki/Main_Page",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList : "public-ldp",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
+ };
+</script>
+</head>
+<body>
+ <section id='abstract'>This document provides best practice
+ guidelines for Implementing Linked Data Platform servers, clients and
+ related systems.</section>
+
+ <section>
+ <h2>Your Title</h2>
+ <p>Your text...</p>
+ </section>
+
+ <section>
+ <h2>Best Practice Category A</h2>
+
+ <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>
+
+ <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>
+
+ <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>
+ <h3>Predicate URIs SHOULD be HTTP URLs</h3>
+ <p>This was removed from the spec:</p>
+ <blockquote>4.1.7 Predicate URIs used in LDPR
+ representations SHOULD be HTTP URLs. These predicate URIs MUST
+ identify LDPRs whose representations are retrievable. LDPR servers
+ SHOULD provide an RDF Schema !RDF-SCHEMA representation of these
+ predicates.</blockquote>
+ <p>
+ As part of the discussion around <a
+ href="http://www.w3.org/2012/ldp/track/issues/9">ISSUE-9</a> it was
+ seen as most likely this should be implementation guidance.
+ </p>
+ </section>
+
+ </section>
+
+ <section>
+ <h2>Best Practice Category B</h2>
+ <section>
+ <h3>Practice 1</h3>
+ <p>Eplurbis unum...</p>
+ </section>
+ <section>
+ <h3>Practice 2</h3>
+ <p>Eplurbis unum...</p>
+ </section>
+ </section>
+
+ <section>
+ <h2>Additional References and Resources</h2>
+ <p>Following are useful references and resources that are not
+ currently found in the ReSpec database. They should either be added
+ to that db or otherwise noted in some way...</p>
+
+
+ <dl class="bibliography">
+ <dt>[Linked Data Glossary]</dt>
+ <dd>
+ W3C Working Group Note, 27 June 2013<br />
+ http://www.w3.org/TR/ld-glossary/<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.
+ </dd>
+ </dl>
+
+ </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>
\ No newline at end of file