Deployment Guide

From Linked Data Platform
Revision as of 20:23, 11 July 2013 by Sspeiche (Talk | contribs)

Jump to: navigation, search

This page collects various informative material, including best practices, design patterns and anti-patterns, related to LDP. It may or may not become a formal deliverable of the Working Group.


This document is now deprecated in favor of the new editor's working draft, LDP Best Practices and Guidelines, which can be found at the following URL:

The editors of the new document are watching this page, so it can still be used to submit new things. The editors plan to remove items from this document as they are formalized in an decent manner for the LDP Best Practices and Guidelines. This page, therefor, can be thought of as something of a submission form (in lieu of or in addition to email to Working Group or editors).

2 Editors

Primary: Cody Secondary: Nandana

3 Name of this document

Meta comment: “Deployment” has a very specific meaning in software engineering. Therefore perhaps call this something else. Proposals:

  • LDP Best Practices: A Guide to Implementation and Deployment
  • LDP Best Practices and Implementer's Guide

4 Use relative URIs

See ldp-ISSUE-29 (Relative URIs): Relative URIs are

  • crucial in creation of resources as the client cannot know what the name of the to be created resource is going to be
  • relative URIs are helpful on the server:
    • 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
    • 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.

5 Represent container membership with hierarchical URIs

  • Hierarchical URIs are good for containers because they enable relativizing.

6 Use fragments as entity identifiers

  • Fragments are nice because they can be expressed as relative URIs on the document describing them.

7 Prefer standard datatypes

This was originally part of old Section 4.1.9 that was deleted from the FPWD based on resolution of ISSUE-6

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:

URI Description Boolean type as specified by XSD Boolean Date type as specified by XSD date Date and Time type as specified by XSD dateTime Decimal number type as specified by XSD Decimal Double floating-point number type as specified by XSD Double Floating-point number type as specified by XSD Float Integer number type as specified by XSD Integer String type as specified by XSD String Binary type as specified by XSD Base64Binary Literal XML value as specified by RDF

8 Re-use established linked data vocabularies instead of (re-)inventing duplicates

This was originally from old section 4.8 that was deleted from the FPWD based on resolution of ISSUE-42. As indicated in that issue, the text below (which was simply copied from the spec) may need further editing.

Common Properties

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.

From Dublin Core URI:

Property Range/DataType Comment
dcterms:contributor dcterms:Agent
dcterms:creator dcterms:Agent
dcterms:created xsd:dateTime
dcterms:description rdf:XMLLiteral Descriptive text about the resource represented as rich text in XHTML format. should include only content that is valid and suitable inside an XHTML
dcterms:identifier rdfs:Literal
dcterms:modified xsd:dateTime
dcterms:relation rdfs:Resource 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.
dcterms:subject rdfs:Resource
dcterms:title rdf:XMLLiteral A name given to the resource. Represented as rich text in XHTML format. should include only content that is valid inside an XHTML element.

The predicate dcterms:type should not be used, instead use rdf:type. [DC-RDF].


Property Range/DataType Comment
rdf:type rdfs:Class The type or types of the resource

From RDF Schema URI:

Property Range/DataType Comment
rdfs:member rdfs:Resource
rdfs:label rdfs:Literal Only use this in vocabulary documents, to define the name of the vocabulary term.

9 Properly use q values

  • Not properly handling q values is a major problem in implementations of content negotiation.

10 Use canonical URIs for identity comparison

  • Location and/or Content-Location header contains canonical URI
  • Clients should use canonical URI when comparing resources for "same-ness" (identity), even if the resources are accessed via distinct URLs.
  • 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.

11 Servers should serve up canonical URLs

This was removed from the spec:

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.

As part of the discussion around ISSUE-49 it was seen as most likely this should be implementation guidance.

12 Representing relationships between resources

This was removed from the spec:

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.

This addresses a misconception that the editors observed. Readers with certain background assume that one always needs a “link resource” to express a relationship. ISSUE-44

13 Predicate URIs SHOULD be HTTP URLs

This was removed from the spec:

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.

As part of the discussion around ISSUE-9 it was seen as most likely this should be implementation guidance.

14 Resources should have type set explicitly

This was removed from the spec:

4.1.5 LDPRs MUST use the predicate rdf:type to

represent the concept of type. The use of non-standard type predicates, as well as dcterms:type, is discouraged, as it is not recommended

by the Dublin Core Metadata Initiative for use with RDF resources !DC-RDF.

15 Additional References and Resources

Linked Data Glossary W3C Working Group Note 27 June 2013 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.

Retrieved from ""