--- a/ldp-bp/ldp-bp.html Sun Dec 15 14:47:17 2013 +0100
+++ b/ldp-bp/ldp-bp.html Sun Dec 29 12:30:43 2013 -0600
@@ -55,6 +55,12 @@
companyURL : "http://base22.com/"
},
{
+ name : "Miguel Esteban Gutiérrez",
+ url: "http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban",
+ company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
+ companyURL : "http://www.oeg-upm.net/"
+ },
+ {
name : "Nandana Mihindukulasooriya",
url : "http://www.nandana.org/",
company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
@@ -85,91 +91,72 @@
// 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",
- localBiblio: {
- "LD-DI": {
- title: "Linked Data - Design Issues",
- href: "http://www.w3.org/DesignIssues/LinkedData.html",
- authors: ["Tim Berners-Lee"],
- //status: "WD"//,
- //deliveredBy: [
- // "http://www.w3.org/2012/ldp/"
- //],
- //publisher: "W3C"
- },
- "LDP-TESTS": {
- title: "Linked Data Platform 1.0 Test Cases",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html",
- authors: [
- "Raúl García-Castro"
- ],
- status: "WD",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LD-GLOSSARY": {
- title: "Linked Data Glossary",
- href: "http://www.w3.org/TR/ld-glossary/",
- authors: [
- "B Hyland", "G Atemezing", "M Pendleton", "B Srivastava"
- ],
- //status: "WD",
- //deliveredBy: [
- // "http://www.w3.org/2012/ldp/"
- //],
- publisher: "W3C"
- },
- "LDP-PRIMER": {
- title: "Linked Data Platforn Primer",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html",
- authors: [
- "Nandana Mihindukulasooriya","Roger Menday"
- ],
- status: "WD",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LDP-UCR": {
- title: "Linked Data Platform Use Cases and Requirements",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html",
- editors: [
- "Steve Battle","Steve Speicher"
- ],
- status: "ED",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LDP1": {
- title: "Linked Data Platform 1.0",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html",
- editors: [
- "Steve Speicher",
- "John Arwe",
- "Ashok Malhotra"
- ],
- status: "ED",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LOD-COMMON-VOCABS": {
- title: "Common Vocabularies / Ontologies / Micromodels ",
- href: "http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies",
- publisher: "SWEO Community Project: Linking Open Data on the Semantic Web"
- },
- "LOV": {
- title: "Linked Open Vocabularies (LOV)",
- href: "http://lov.okfn.org/dataset/lov/",
- publisher: "Open Knowledge Foundation (OKFN)"
- }
+ localBiblio : {
+ "LD-DI" : {
+ title : "Linked Data - Design Issues",
+ href : "http://www.w3.org/DesignIssues/LinkedData.html",
+ authors : [ "Tim Berners-Lee" ],
+ //status: "WD"//,
+ //deliveredBy: [
+ // "http://www.w3.org/2012/ldp/"
+ //],
+ //publisher: "W3C"
+ },
+ "LDP-TESTS" : {
+ title : "Linked Data Platform 1.0 Test Cases",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html",
+ authors : [ "Raúl García-Castro" ],
+ status : "WD",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LD-GLOSSARY" : {
+ title : "Linked Data Glossary",
+ href : "http://www.w3.org/TR/ld-glossary/",
+ authors : [ "B Hyland", "G Atemezing", "M Pendleton",
+ "B Srivastava" ],
+ //status: "WD",
+ //deliveredBy: [
+ // "http://www.w3.org/2012/ldp/"
+ //],
+ publisher : "W3C"
+ },
+ "LDP-PRIMER" : {
+ title : "Linked Data Platforn Primer",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html",
+ authors : [ "Nandana Mihindukulasooriya", "Roger Menday" ],
+ status : "WD",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LDP-UCR" : {
+ title : "Linked Data Platform Use Cases and Requirements",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html",
+ editors : [ "Steve Battle", "Steve Speicher" ],
+ status : "ED",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LDP1" : {
+ title : "Linked Data Platform 1.0",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html",
+ editors : [ "Steve Speicher", "John Arwe", "Ashok Malhotra" ],
+ status : "ED",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LOD-COMMON-VOCABS" : {
+ title : "Common Vocabularies / Ontologies / Micromodels ",
+ href : "http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies",
+ publisher : "SWEO Community Project: Linking Open Data on the Semantic Web"
+ },
+ "LOV" : {
+ title : "Linked Open Vocabularies (LOV)",
+ href : "http://lov.okfn.org/dataset/lov/",
+ publisher : "Open Knowledge Foundation (OKFN)"
+ }
}
-
+
};
// Replaces HTML characters (brackets and quotes) with legal HTML representations
@@ -190,7 +177,7 @@
}
</script>
-
+
</head>
@@ -199,623 +186,809 @@
<body>
- <section id='abstract'>
- This document provides best practices and general guidelines for implementing
- Linked Data Platform servers, clients and related systems.
- </section>
-
+ <section id='abstract'>This document provides best practices
+ and general guidelines for implementing Linked Data Platform servers
+ and clients.</section>
+
+ <section>
+
+ <h2>About this Document</h2>
+
<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 LDP Primer [[LDP-PRIMER]], 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 follows:</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 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 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 Terminology section of the LDP specification [[LDP1]] as well as the Linked Data Glossary [[LD-GLOSSARY]]
- 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>
- 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>Linked Data Glossary</strong> [[LD-GLOSSARY]] - 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> [[LDP1]] - 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><strong>Linked Data Platform 1.0 Test Cases</strong> [[LDP-TESTS]] - A standard set of tests provided by the W3C, which can be use to verify an implementation's conformance to the LDP specification.</li>
- <li><strong>Linked Data Platform Primer</strong> [[LDP-PRIMER]] - 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> [[LDP-UCR]] - 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>
+
+ <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 LDP Primer [[LDP-PRIMER]], 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>
+
+ <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 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 one should implement
+ LDP servers and clients. 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 your knowledge and
+ understanding, but that may not be directly applicable to your
+ implementation or recognized by consensus as a 'best practice'.</dd>
+ </dl>
+
+ <p>Please see the Terminology section of the LDP specification
+ [[LDP1]] as well as the Linked Data Glossary [[LD-GLOSSARY]] 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>
+ 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> [[RDF-SCHEMA]] - 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</strong> - 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> [[TURTLE]] -
+ 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> [[LD-GLOSSARY]] - 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> [[LDP1]] - 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><strong>Linked Data Platform 1.0 Test Cases</strong>
+ [[LDP-TESTS]] - a standard set of tests provided by the W3C, which
+ can be use to verify an implementation's conformance to the LDP
+ specification.</li>
+ <li><strong>Linked Data Platform Primer</strong> [[LDP-PRIMER]]
+ - 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> [[LDP-UCR]] - 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>
+
+ <section>
+
+ <h2>Best Practices</h2>
+
<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 [[LD-DI]]]. 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="Representation of an LDPR 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 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>
+ <h3>Predicate URIs should be HTTP URLs</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>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>
- <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>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 [[LD-DI]]]. 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>
- <pre title="Representation of http://example.org/container1/ with absolute URIs"
+ <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="Representation of an LDPR 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 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>
+
+ <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>
+
+ <pre
+ title="Representation of http://example.org/container1/ with absolute URIs"
class='example' data-include='rdf-absolute-uris.ttl'
data-oninclude='fixCode'></pre>
- <pre title="Representation of http://example.org/container1/ with relative URIs"
+ <pre
+ title="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 omitted, 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 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>
-
- <h3>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 the 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, you can easily discern the URI of the parent resource, which holds the attachments. You can also discern the base container for other sibling resources by moving up the hierarchy, which is implied by the URI. You might also go down the hierarchy to fetch meta-data or binary content using a URI such as the following:</p>
-
- <p><code>http://example.org/bugs/2314/attachments/1</code></p>
-
- <p>As you can see, in addition to making the use of relative URIs possible, hierarchical URIs make interacting with resources easier because they represent the actual structure of the underlying graph.</p>
-
- </section>
-
-
- <section>
-
- <!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
-
- <h4>Include a trailing slash in container URIs</h4>
-
- <p>When representing container membership with hierarchical URLs, there is an advantage to including the trailing
- slash in the URI of a given container. Take the following container URI for example:</p>
+ </dd>
- <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>
-
- <pre title="A simple container" class='example' data-include='trailing-slash-1.ttl' data-oninclude='fixCode'></pre>
-
- <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>
-
- <pre title="Container URI is http://example.org/container1/" class='example' data-include='trailing-slash-2.ttl' data-oninclude='fixCode'></pre>
-
- <p>But suppose that we ommit the trailing slash, issued an HTTP GET, and the container returned the representation
- shown above. This could produce a graph that is isomorphic to the following:</p>
-
- <pre title="Container URI is http://example.org/container1" class='example' data-include='trailing-slash-3.ttl' data-oninclude='fixCode'></pre>
-
- <p>That is not what was intended. The returned document would have to be more verbose:</p>
-
- <pre title="Container URI is http://example.org/container1" class='example' data-include='trailing-slash-4.ttl' data-oninclude='fixCode'></pre>
-
- <p>So, clearly, the better solution is to ensure that container URIs end with a trailing slash.</p>
+ <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 that information changes. This can make
+ moving resources to new servers or to a new position in a
+ containment hierarchy easier.</dd>
- </section>
-
-
- <section>
-
- <h3>Use fragments as object identifiers</h3>
-
- <p>The fragment identifier introduced by a hash mark (<b><code>#</code></b>) is the optional last part of a URI for an object, which is typically used to identify a subordinate or related object.</p>
+ <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>
- <p>
- Take the URI, <code>http://www.example.org/products#item10245</code>, for example. The base 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>
+ <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>
- <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>
+ <section>
- <p>
- First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe
- the resources foo, bar and baz, which 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>). The full URI is assumed to
- be the base URI, plus the hash mark, and the fragment identifier.
- </p>
+ <h3>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 the 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, you can easily discern the URI of the parent
+ resource, which holds the attachments. You can also discern the base
+ container for other sibling resources by moving up the hierarchy,
+ which is implied by the URI. You might also go down the hierarchy to
+ fetch meta-data or binary content using a URI such as the following:</p>
+
+ <p>
+ <code>http://example.org/bugs/2314/attachments/1</code>
+ </p>
+
+ <p>As you can see, in addition to making the use of relative URIs
+ possible, hierarchical URIs make interacting with resources easier
+ because they represent the actual structure of the underlying graph.</p>
+
+ </section>
- <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 you'd need to create and publish multiple
- documents, perhaps also having to setup 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>
- <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><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>
- <h3>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 [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] 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#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>
+ <section>
- <h3>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>
-
- <h4>Common Properties</h4>
-
- <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>. [[DC-RDF]].</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>
-
+ <!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
-
- </section>
-
-
- <section>
- <h3>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>Refer to Section 14, Header Field Definitions, in the [[HTTP11]] specification to understand the proper use and evaluation
- of qvalues for both client and server implementations.</p>
-
- </section>
-
- <section>
- <h3>Respond with canonical URLs and use them for identity comparison</h3>
-
- <p>Clients can access an LDPR using multiple URLs. An LDPR server should respond to each of those requests
- using a single consistent URL, a canonical URL, for the LDPR. This canonical 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 to either URL with a single (canonical) URL.</p>
-
- <p>Clients should use the canonical URL as an LDPR's identity; for example, when determining if two URLs refer to the same resource clients should compare the canonical URLs, not the URLs used to access the resources.</p>
+ <h4>Include a trailing slash in container URIs</h4>
- </section>
-
- <section>
- <h3>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><!-- End Best Practices 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>Finding established vocabularies</h3>
-
- <p>Following are some sources which may be useful for finding and leveraging pre-existing, common, and well-established vocabularies.</p>
-
- <p style="clear:both">
- <img src="lov-thumb.jpg" width="150" style="float:left;margin: 0 20px 20px 0">
- <a href="http://lov.okfn.org" target="_blank">Linked Open Vocabularies (LOV)</a><br/>
- LOV is an entry point to the growing ecosystem of linked open vocabularies (RDFS or OWL ontologies) used in the Linked Data Cloud.
- There you can find vocabularies listed and individually described by metadata, classified by vocabulary spaces, and interlinked using the dedicated vocabulary VOAF.
- The site allows you 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. You can also suggest a new vocabulary to add to LOV. [[LOV]]</p>
-
- <p style="clear:both">
- <img src="lodCommonVocabs-thumb.jpg" width="150" style="float:left;margin: 0 20px 20px 0">
- <a href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies" target="_blank">Common Vocabularies / Ontologies / Micromodels</a><br/>
- A wiki list maintained by the Linked Data LOD community project. [[LOD-COMMON-VOCABS]]</p>
-
- <div style="clear:both"></div>
-
-
-
- </section>
-
- </section><!-- End Guidelines 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>
- <p>To Ashok Malhotra, Melvin Carvalho, Richard Cyganiak, Steve Speicher, and Miguel Esteban Gutiérrez for providing recommendations for improvement to the editors.</p>
+ <p>When representing container membership with hierarchical URLs,
+ there is an advantage to including the trailing slash in the URI of
+ a given container. 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>
+
+ <pre title="A simple container" class='example'
+ data-include='trailing-slash-1.ttl' data-oninclude='fixCode'></pre>
+
+ <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>
+
+ <pre title="Container URI is http://example.org/container1/"
+ class='example' data-include='trailing-slash-2.ttl'
+ data-oninclude='fixCode'></pre>
+
+ <p>But suppose that we ommit the trailing slash, issued an HTTP
+ GET, and the container returned the representation shown above. This
+ could produce a graph that is isomorphic to the following:</p>
+
+ <pre title="Container URI is http://example.org/container1"
+ class='example' data-include='trailing-slash-3.ttl'
+ data-oninclude='fixCode'></pre>
+
+ <p>That is not what was intended. The returned document would
+ have to be more verbose:</p>
+
+ <pre title="Container URI is http://example.org/container1"
+ class='example' data-include='trailing-slash-4.ttl'
+ data-oninclude='fixCode'></pre>
+
+ <p>So, clearly, the better solution is to ensure that container
+ URIs end with a trailing slash.</p>
+
</section>
-
+
+ <section>
+
+ <h3>Use fragments as object identifiers</h3>
+
+ <p>
+ The fragment identifier introduced by a hash mark (<b><code>#</code></b>)
+ is the optional last part of a URI for an object, which is typically
+ used to identify a subordinate or related object.
+ </p>
+
+ <p>
+ Take the URI,
+ <code>http://www.example.org/products#item10245</code>
+ , for example. The base 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 that you want to describe the resources foo,
+ bar and baz, which 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>
+ ). The full URI is assumed to be the base URI, plus the hash mark,
+ and 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 you'd need to
+ create and publish multiple documents, perhaps also having to setup
+ 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>
+ <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>
+ <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>
+ <h3>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 [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] 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#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>
+ 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>
+
+ <h4>Common Properties</h4>
+
+ <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>
+ . [[DC-RDF]].
+ </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>
+ <h3>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>Refer to Section 14, Header Field Definitions, in the
+ [[HTTP11]] specification to understand the proper use and evaluation
+ of qvalues for both client and server implementations.</p>
+
+ </section>
+
+ <section>
+ <h3>Respond with canonical URLs and use them for identity
+ comparison</h3>
+
+ <p>Clients can access an LDPR using multiple URLs. An LDPR server
+ should respond to each of those requests using a single consistent
+ URL, a canonical URL, for the LDPR. This canonical 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 to either URL
+ with a single (canonical) URL.</p>
+
+ <p>Clients should use the canonical URL as an LDPR's identity;
+ for example, when determining if two URLs refer to the same resource
+ clients should compare the canonical URLs, not the URLs used to
+ access the resources.</p>
+
+ </section>
+
+ <section>
+ <h3>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>
+ <!-- End Best Practices 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>Finding established vocabularies</h3>
+
+ <p>Following are some sources which may be useful for finding and
+ leveraging pre-existing, common, and well-established vocabularies.</p>
+
+ <p style="clear: both">
+ <img src="lov-thumb.jpg" width="150"
+ style="float: left; margin: 0 20px 20px 0"> <a
+ href="http://lov.okfn.org" target="_blank">Linked Open
+ Vocabularies (LOV)</a><br /> LOV is an entry point to the growing
+ ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
+ in the Linked Data Cloud. There you can find vocabularies listed and
+ individually described by metadata, classified by vocabulary spaces,
+ and interlinked using the dedicated vocabulary VOAF. The site allows
+ you 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. You can also suggest a new vocabulary to add to
+ LOV. [[LOV]]
+ </p>
+
+ <p style="clear: both">
+ <img src="lodCommonVocabs-thumb.jpg" width="150"
+ style="float: left; margin: 0 20px 20px 0"> <a
+ href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"
+ target="_blank">Common Vocabularies / Ontologies / Micromodels</a><br />
+ A wiki list maintained by the Linked Data LOD community project.
+ [[LOD-COMMON-VOCABS]]
+ </p>
+
+ <div style="clear: both"></div>
+
+
+
+ </section>
+
+ </section>
+ <!-- End Guidelines 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>
+ <p>To Ashok Malhotra, Melvin Carvalho, Richard Cyganiak, Steve
+ Speicher, and Miguel Esteban Gutiérrez for providing recommendations
+ for improvement to the editors.</p>
+ </section>
+
+
</body>
</html>