Deployment Guide

From Linked Data Platform
Revision as of 23:02, 16 January 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.

1 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.

2 Represent container membership with hierarchical URIs

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

3 Use fragments as entity identifiers

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

4 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

5 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

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. The Range column in the tables below identify the recommended rdfs:range for the properties.

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.

6 Properly use q values

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

7 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.
Retrieved from ""