The Linked Data Platform specification, informally LDP, describes the use of HTTP for accessing, updating, creating and deleting resources from servers that expose their resources as Linked Data. This document describes the conditions that LDP servers must satisfy in order to be conformant with the specification and presents a common format for describing LDP test cases and server results. These test cases both illustrate the features of the specification and can be used for testing conformance.

Introduction

This document describes a test suite that can be used to evaluate the conformance of LDP servers to the LDP specification [[LINKED-DATA-PLATFORM]]. The document also presents the design principles that guided the development of the test suite, a testing process, and a common format for describing test cases and server results.
The purpose of the test cases is to illustrate the specification features and to help in testing conformance. The provided set of test cases is "incomplete" in the sense that passing all the tests does not prove that a given system conforms to the LDP specification; failing a test does, however, prove that the system does not conform to the specification.
The presented format is intended to facilitate the use of tests by LDP server developers, e.g., in a test harness, as well as the extension of the test suite with new tests. Developers can check the LDP Primer [[LDP-PRIMER]] for concrete examples of inputs and expected outputs that can be used for testing.

Design principles

Generic vs domain-specific servers

There will be two types of systems implementing the LDP specification:

In order to cover both types of systems, we do not provide specific input data in the test suite. It is up to the evaluator to define specific input data for a certain system. Evaluators must include these input data along with the results when reporting the results of a certain system.

Protocol evaluation vs data evaluation

The LDP specification includes restrictions on LDP servers at the protocol level and at the data level. Currently, the restrictions at the data level are minimal and servers are not forced to have a certain behaviour when processing LDPR representations. Therefore, the test suite evaluates LDP servers at a protocol level; the only exception is in the case of LDPCs, since they are required to include an rdf.type statement in their representation.

It is out of the scope of the test suite to test LDP servers in terms of the restrictions imposed by their underlying data models.

Test suite coverage

This test suite only covers those absolute requirements present in the LDP specification (as stated by the use of the MUST key word). This set of absolute requirements identifies the core subset of the LDP specification, LDP Core from now on, and any LDP server that satisfies these absolute requirements will be an LDP Core conformant server.

It is out of the scope of this test suite to test other levels of conformance in terms of optional capabilities (e.g., paging).

Furthermore, the LDP specification [[LINKED-DATA-PLATFORM]] contains the following absolute requirements for LDP Core that are not directly testable and, therefore, are not covered by the current test suite:

Separation of results and assertions

Instead of defining expected results for tests, which will be dependent on specific implementations, we have defined the assertions to be made over test results. In order to successfully pass a test, all of the assertions must be satisfied.

Separating test outputs and assertions has other benefits: it makes simpler to report tool results and assertions can be made by a third party.

Traceability of test cases

Any test case and its produced results and assertions should be related to those documents that are relevant for it (e.g., specifications, uses cases, etc.).

Testing process

The LDP Test Cases are defined in this same page, which is annotated using RDFa so that it can be consumed both by persons and machines. The testing process is composed of two steps, depicted in the figure below.

  1. The person or agent in charge of executing the test cases in a specific LDP server will take the test case definitions and run every test case on the LDP server. It is recommended (but not required) that test execution is automated. The execution of test cases must produce a test execution report for the LDP server, in RDF format, that contains for every test case: the specific inputs used during its execution, the produced outputs, and the assertion of whether the test case is passed. The test execution report must be available in the Web.
  2. A report generator software will take all the LDP server execution reports and will generate an implementation report that includes the results of all the LDP servers.

Your browser does not support SVG.

Describing testing artifacts in RDF

Namespaces used

The following vocabularies are reused for describing the testing artifacts: DOAP ( doap ), Dublin Core ( dc ) [[DC11]], FOAF ( foaf ) [[FOAF]], HTTP Vocabulary in RDF ( ht ) [[HTTP-IN-RDF]], and W3C Test Metadata ( td ) [[TEST-METADATA]].

All the new required entities that are not covered by those vocabularies have been defined under a new namespace ( tn ). Besides, the LDP test cases have been defined under their own namespace ( ldptc ).

Next we present the definition of these namespaces and of all the namespaces used in the examples.

cnt: <http://www.w3.org/2011/content#>
dc: <http://purl.org/dc/terms/>
doap: <http://usefulinc.com/ns/doap#>
earl: <http://www.w3.org/ns/earl#>
foaf: <http://xmlns.com/foaf/0.1/>
ht: <http://www.w3.org/2011/http#>
httph: <http://www.w3.org/2011/http-headers#>
ldptc: <http://www.w3.org/TR/ldp/TestCases#>
td: <http://www.w3.org/2006/03/test-description#>
tn: <http://ldp.example.org/NewTestDefinitions#>

Test case description

A test case is defined as an instance of the td:TestCase class and it can be further described using the following properties:

An excerpt is defined as an instance of the tn:Excerpt class and it can be further described using the following properties:

A test input is defined as an instance of the td:TestInput class and it can be further described using the following properties:

A test output is defined as an instance of the td:TestOutput class and it can be further described using the following properties:

In the LDP test cases, test outputs are expected to be HTTP responses ( ht:Response ).

A step in the test process is defined as an instance of the td:Step class and it can be further described using the following properties:

In the LDP test cases, steps are expected to be HTTP requests ( ht:Request ).

A test assertion is defined as an instance of the td:TestAssertion class and it can be further described using the following properties:

The following example contains the description of one of the LDP test cases.

:TCR1 a td:TestCase;
         rdfs:label "TC-R1";
         dc:title "GET on an LDPR";
         dc:description "Tests making a GET request on an existing LDPR";
         dc:contributor :RaulGarciaCastro;
         td:reviewStatus td:unreviewed;
         rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
         td:specificationReference [
             a tn:Excerpt;
             rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
             tn:includesText "4.2.8 LDPR server responses MUST use entity tags (either weak or strong ones) as response ETag header values.".
           ],
         	                       [
         	 a tn:Excerpt;
             rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
             tn:includesText "4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]".
           ],
         	                       [
         	 a tn:Excerpt;
             rdfs:seeAlso <http://www.w3.org/TR/ldp/>;
             tn:includesText "4.3.1 LDPR servers MUST support the HTTP GET Method for LDPRs.".
           ];
         td:input :TCR1-I1-LDPR-URI;
         td:precondition "The LDP server contains an LDPR at <LDPR URI>";
         tn:output :TCR1-O1-Response-1-GET;
         tn:testProcess (:TCR1-RQ1-GET-LDPR-URI);
         tn:testAssertion :TCR1-A1-Response-1-GET.

:RaulGarciaCastro a foaf:Person;
                    rdfs:label "Raúl García-Castro";
                    owl:sameAs <http://www.garcia-castro.com/#me>.

:TCR1-I1-LDPR-URI a tn:TestInput;
           dc:title "<LDPR URI>";
           dc:description "The URI of an LDPR".

:TCR1-O1-Response-1-GET a tn:TestOutput;
            a ht:Response;
            tn:fromStep :TCR1-RQ1-GET-LDPR-URI;
            dc:title "<Response 1 GET>";
            dc:description "The response of the GET request in step 1".

:TCR1-RQ1-GET-LDPR-URI a tn:Step;
            a ht:Request;
            dc:description "GET <LDPR URI>";
            tn:usesInput :TCR1-I1-LDPR-URI.

:TCR1-A1-Response-1-GET a tn:TestAssertion;
            tn:outputAsserted :TCR1-O1-Response-1-GET;
            dc:title "GET correct";
            dc:description """[Status-Line].Status-Code = 2xx
        [response-header].ETag exists
        [response-header].Link includes ldp:Resource; rel="type"""".

Execution report description

A test execution is defined as an instance of the tn:TestExecution class and it can be further described using the following properties:

A test input value is defined as an instance of the tn:TestInputValue class and it can be further described using the following properties:

A test output value is defined as an instance of the tn:TestOutputValue class and it can be further described using the following properties:

In the LDP test cases, test output values are expected to be HTTP responses ( ht:Response ).

The following example contains the description of one test execution.

:TCR1-Execution a tn:TestExecution;
                tn:testExecuted ldptc:TCR1;
                tn:subjectTested :SomeServer;
                dc:date "2013-03-30T09:30:10";
                tn:inputUsed [
                  a tn:TestInputValue ;
                  tn:relatedInput :TCR1-I1-LDPR-URI ;
                  tn:inputValue <http://www.example.org/MyResource> .
                ];
                tn:outputProduced [
                  a tn:TestOutputValue ;
                  tn:relatedOutput :TCR1-O1-Response-1-GET ;
                  tn:outputValue :TCR1-Exec-Response-1-GET .
                ].

:SomeServer a doap:Project;
            doap:name "Sample server".

:TCR1-Exec-Response-1-GET a ht:Response;
    ht:httpVersion "1.1";
    dc:date "2013-03-30T09:30:10";
    ht:sc <http://www.w3.org/2011/http-statusCodes#OK>;
    ht:statusCodeValue "200";
    ht:reasonPhrase "OK";
    ht:headers (
      [
        a ht:ResponseHeader;
        ht:hdrName httph:etag;
        ht:fieldName "ETag";
        ht:fieldValue "hd73hck43".
      ]
      [
        a ht:EntityHeader;
        ht:hdrName httph:content-type;
        ht:fieldName "Content-Type";
        ht:fieldValue "text/turtle; charset=utf-8".
      ]
    );
    ht:body [
      a cnt:ContentAsText ;
      cnt:chars """
			@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
			@prefix dc: <http://purl.org/dc/terms/>.
			@prefix ldp: <http://www.w3.org/ns/ldp#>.

			<http://example.org/MyResource>
			   a ldp:Resource;
			   dc:title "My LDP resource".
      """;
      cnt:characterEncoding "UTF-8".
    ].

Test case assertion description

An assertion is defined as an instance of the earl:Assertion class and it can be further described using the following properties:

The following example contains the description of one test assertion.

:TCR1-Assertion-SomeServer a earl:Assertion;
                earl:subject sr:SomeServer;
                earl:test ldptc:TCR1;
                tn:fromTestExecution sr:TCR1-Execution;
                dc:date "2013-03-30T09:30:10";
                earl:assertedBy :Validator;
                earl:mode:  earl:automatic;
                earl:result [
                  a earl:OutcomeValue ;
                  earl:outcome earl:passed .
                ].

:Validator a doap:Project;
            doap:name "Some validator".

Tests for LDPRs

These tests involve only LDPRs.

TC-R1. GET on an LDPR

Tests making a GET request on an existing LDPR.

Contributor: Raúl García-Castro

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDPR URI>

Output

Assertions

TC-R2. HEAD on an LDPR

Tests making a HEAD request on an LDPR.

Contributor: Raúl García-Castro

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Hypertext Transfer Protocol - HTTP/1.1:

Input

Preconditions

Process

  1. HEAD <LDPR URI>

Output

Assertions

TC-R3. OPTIONS on an LDPR

Tests making an OPTIONS request on an LDPR.

Contributor: Raúl García-Castro

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. OPTIONS <LDPR URI>

Output

Assertions

Tests for LDP Basic Containers

These tests involve LDP-BCs and LDPRs.

TC-BC1. GET on an empty LDP-BC

Tests making a GET request on an empty LDP Basic Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-BC URI>

Output

Assertions

TC-BC2. GET on a non-empty LDP-BC

Tests making a GET request on a non-empty LDP Basic Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-BC URI>

Output

Assertions

TC-BC3. POST an LDP-NR on an LDP-BC

Tests making a POST request of an LDP-NR on an LDP Basic Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-BC URI>
  2. POST <LDP-BC URI>
    • [message-body] = <LDP-NR representation>
  3. GET <LDP-BC URI>
  4. GET <Response 2 POST>.[response-header].Location

Output

Assertions

TC-BC4. POST an LDP-RS on an LDP-BC

Tests making a POST request of an LDP-RS on an LDP Basic Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-BC URI>
  2. POST <LDP-BC URI>
    • [entity-header].Content-type = text/turtle
    • [message-body] = <LDP-RS representation>
  3. GET <LDP-BC URI>
  4. GET <Response 2 POST>.[response-header].Location

Output

Assertions

TC-BC5. HEAD on an LDP-BC

Tests making a HEAD request on an LDP Basic Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Hypertext Transfer Protocol - HTTP/1.1:

Input

Preconditions

Process

  1. HEAD <LDP-BC URI>

Output

Assertions

TC-BC6. OPTIONS on an LDP-BC

Tests making a OPTIONS request on an LDP Basic Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. OPTIONS <LDP-BC URI>

Output

Assertions

Tests for LDP Direct Containers

These tests involve LDP-DCs and LDPRs.

TC-DC1. GET on an empty LDP-DC

Tests making a GET request on an empty LDP Direct Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-DC URI>

Output

Assertions

TC-DC2. GET on a non-empty LDP-DC

Tests making a GET request on a non-empty LDP Direct Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-DC URI>
  2. GET <R URI>

Output

Assertions

TC-DC3. POST an LDP-NR on an LDP-DC

Tests making a POST request of an LDP-NR on an LDP Direct Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-DC URI>
  2. POST <LDP-DC URI>
    • [message-body] = <LDP-NR representation>
  3. GET <LDP-DC URI>
  4. GET <Response 2 POST>.[response-header].Location
  5. GET <R URI>

Output

Assertions

TC-DC4. POST an LDP-RS on an LDP-DC

Tests making a POST request of an LDP-RS on an LDP Direct Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-DC URI>
  2. POST <LDP-DC URI>
    • [entity-header].Content-type = text/turtle
    • [message-body] = <LDP-RS representation>
  3. GET <LDP-DC URI>
  4. GET <Response 2 POST>.[response-header].Location
  5. GET <R URI>

Output

Assertions

TC-DC5. HEAD on an LDP-DC

Tests making a HEAD request on an LDP Direct Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Hypertext Transfer Protocol - HTTP/1.1:

Input

Preconditions

Process

  1. HEAD <LDP-DC URI>

Output

Assertions

TC-DC6. OPTIONS on an LDP-DC

Tests making a OPTIONS request on an LDP Direct Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. OPTIONS <LDP-DC URI>

Output

Assertions

Tests for LDP Indirect Containers

These tests involve LDP-ICs and LDPRs.

TC-IC1. GET on an empty LDP-IC

Tests making a GET request on an empty LDP Indirect Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-IC URI>

Output

Assertions

TC-IC2. GET on a non-empty LDP-IC

Tests making a GET request on a non-empty LDP Indirect Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-IC URI>
  2. GET <R URI>
  3. GET <C URI>

Output

Assertions

TC-IC3. POST an LDP-RS on an LDP-IC

Tests making a POST request of an LDP-RS on an LDP Indirect Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. GET <LDP-IC URI>
  2. POST <LDP-IC URI>
    • [entity-header].Content-type = text/turtle
    • [message-body] = <LDP-RS representation>
  3. GET <LDP-IC URI>
  4. GET <Response 2 POST>.[response-header].Location
  5. GET <R URI>

Output

Assertions

TC-IC4. HEAD on an LDP-IC

Tests making a HEAD request on an LDP Indirect Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Hypertext Transfer Protocol - HTTP/1.1:

Input

Preconditions

Process

  1. HEAD <LDP-IC URI>

Output

Assertions

TC-IC5. OPTIONS on an LDP-IC

Tests making a OPTIONS request on an LDP Indirect Container.

Contributor: Fernando Serena

Status: Unreviewed

Related specification

Linked Data Platform 1.0:

Input

Preconditions

Process

  1. OPTIONS <LDP-IC URI>

Output

Assertions

Change history

Editor TODOs and notes