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 Editors
- 2 Name of this document
- 3 Use relative URIs
- 4 Represent container membership with hierarchical URIs
- 5 Use fragments as entity identifiers
- 6 Prefer standard datatypes
- 7 Re-use established linked data vocabularies instead of (re-)inventing duplicates
- 8 Properly use q values
- 9 Use canonical URIs for identity comparison
- 10 Servers should serve up canonical URLs
- 11 Representing relationships between resources
- 12 Predicate URIs SHOULD be HTTP URLs
Primary: Cody Secondary: Nandana
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
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.
Represent container membership with hierarchical URIs
- Hierarchical URIs are good for containers because they enable relativizing.
Use fragments as entity identifiers
- Fragments are nice because they can be expressed as relative URIs on the document describing them.
Prefer standard datatypes
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:
|http://www.w3.org/2001/XMLSchema#boolean||Boolean type as specified by XSD Boolean|
|http://www.w3.org/2001/XMLSchema#date||Date type as specified by XSD date|
|http://www.w3.org/2001/XMLSchema#dateTime||Date and Time type as specified by XSD dateTime|
|http://www.w3.org/2001/XMLSchema#decimal||Decimal number type as specified by XSD Decimal|
|http://www.w3.org/2001/XMLSchema#double||Double floating-point number type as specified by XSD Double|
|http://www.w3.org/2001/XMLSchema#float||Floating-point number type as specified by XSD Float|
|http://www.w3.org/2001/XMLSchema#integer||Integer number type as specified by XSD Integer|
|http://www.w3.org/2001/XMLSchema#string||String type as specified by XSD String|
|http://www.w3.org/2001/XMLSchema#base64Binary||Binary type as specified by XSD Base64Binary|
|http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral||Literal XML value as specified by RDF|
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.
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: http://purl.org/dc/terms/
|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: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: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].
From RDF URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#
|rdf:type||rdfs:Class||The type or types of the resource|
From RDF Schema URI: http://www.w3.org/2000/01/rdf-schema#
|rdfs:label||rdfs:Literal||Only use this in vocabulary documents, to define the name of the vocabulary term.|
Properly use q values
- Not properly handling q values is a major problem in implementations of content negotiation.
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.
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.
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.
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-SCHEMArepresentation of these predicates.
As part of the discussion around ISSUE-9 it was seen as most likely this should be implementation guidance.