Skip to content

Files

Latest commit

author
Tom Johnson
Simplify member triples handling; add support for arbitrary members
Sep 26, 2016
8a8eafd · Sep 26, 2016

History

History
283 lines (219 loc) · 11 KB

IMPLEMENTATION.md

File metadata and controls

283 lines (219 loc) · 11 KB

LDP Implementation Overview

4.2 Resource

4.2.1 General

  • 4.2.1.1: HTTP 1.1 is supported through Rack. Implementers can use Rackup, Sinatra, Rails, and other Rack-driven frameworks to fully support HTTP 1.1 in their servers.
  • 4.2.1.2: Both LDP-RSs and LDP-NRs are supported. LDP-RS is the default interaction model; clients must request an LDP-NR specificially at time of creation.
  • 4.2.1.3: Etags are generated for all LDPRs and returned for all requests to the resource.
  • 4.2.1.4: Link headers for the returned resource are added by Rack::LDP::Headers middleware. The requirement to return Link headers for the requested resource is ignored in the case of successful POST requests; instead, the headers for the created resource are given.
  • 4.2.1.5: Relative URI resolution in RDF graphs is handled with RDF::Reader#base_uri. This is tested for Turtle input.
  • 4.2.1.6: Constraints are published in the {CONSTRAINED_BY.md} file in this repository. Additional, implementation specific constraints should be published by the server implementer and added to the headers for the server.

4.2.2 HTTP GET

  • 4.2.2.1: LDPRs support GET.
  • 4.2.2.2: The "Allow" headers specified for OPTIONS are returned with all requests for a given resource; this is handeled by the Rack::LDP::Headers middleware.

4.2.3 HTTP POST

  • POST is supported for LDP Containers, constranits are published in {CONSTRAINED_BY.md}. See: 4.2.1.6 for details.

4.2.4 HTTP PUT

  • 4.2.4.1: RDFSources completely replace the content of existing graphs with the graph in the PUT request body. Any properties to be handled by the server with update restrictions are left to implementers to enforce.
  • 4.2.4.2: See: 4.2.4.1
  • 4.2.4.3: Server allows client to modify all content except that explicitly excluded by LDP (i.e. server-managed-triples), which are handled as described under relevant sections.
  • 4.2.4.4: Server persists all content PUT to LDP-RS's, per 4.2.4.1.
  • 4.2.4.5: [IGNORED SHOULD] Etags are checked as specified IF an If-Match header is present. If-Match headers are NOT required, and requests without them will operate as though the correct Etag has been given. We consider "clients SHOULD use the HTTP If-Match header".
  • 4.2.4.6: Sending a PUT request to a non-existant Resource creates a Resource at that URI with the selected interaction model (defaulting to ldp:RDFSource). The created Resource will not be in any container.

4.2.5 HTTP DELETE

  • DELETE is supported

4.2.6 HTTP HEAD

  • 4.2.6.1: HEAD is supported. See: 4.2.2.2 for details on HTTP headers.

4.2.7 HTTP PATCH

  • PATCH support is implemented with the LDPatch format and with SPARQL Update.

4.2.8 HTTP OPTIONS

  • 4.2.8.1: OPTIONS is supported for all resources.
  • 4.2.8.2: See: 4.2.2.2 for details on HTTP headers.

4.3 LDP RDFSource

4.3.1 General

  • 4.3.1.1: Each LDP-RS is an LDPR as described in this reports description of 4.2.
  • 4.3.1.2: [IGNORING SHOULD] Enforcement of the presence rdf:type is left to the client and/or server implementer. This software does not add or manage rdf:type in its representations.
  • 4.3.1.3: See: 4.3.1.2.
  • 4.3.1.4: See: 4.2.2.1. Content negotiation for returned RDF representations is handled by Rack::LDP::ContentNegotiation, which inherits Rack::LinkedData::ContentNegotiation.
  • 4.3.1.5-6: Vocabulary use is left to the client.
  • 4.3.1.7-9: These are constraints on the client, not addressed by this software.
  • 4.3.1.10: No specialized rules about update or graph contents are enforced by this software. It requires no inferencing.
  • 4.3.1.11-13: These are constraints on the client, not addressed by this software.

4.3.2 HTTP GET

  • 4.3.2.1: [UNKNOWN] The default return type is text/turtle. No testing has been performed for the tie breaks prescribed in this section. Content negotiation is handled by Rack::LDP::ContentNegotiation.
  • 4.3.2.2: The default return type is text/turtle.
  • 4.3.2.3: [UNKNOWN] Content negotiation for explicit application/ld+json requests is functional. No testing has been performed for the tie breaks prescribed in this section.

4.4 Non-RDFSource

4.4.1 General

  • 4.4.1.1: Each LDP-NR is an LDPR as described in this reports description of 4.2. LDP-NRs are persisted through a StorageAdapter allowing easily swappable approaches to persistence.
  • 4.4.1.2: LDP-NRs include the specified Link header on all requests.

5.2 Container

5.2.1 General

  • 5.2.1.1: Each LDPC is an LDP-RS as described in this report's description of 4.2.
  • 5.2.1.2-3: rdf:type is left to the client and/or implementer.
  • 5.2.1.4: Link headers for type are added for all Resources; See: 4.2.1.4.
  • 5.2.1.5: [IGNORING SHOULD] Client hints are unimplemented. We are considering including them in future development. [TODO]

5.2.2 HTTP GET

  • 5.2.2.1: See: 4.3.2.1.

5.2.3 HTTP POST

  • 5.2.3.1: Server responds 201 unless an error is thrown while completing the POST.
  • 5.2.3.2: Server adds a containment triple with predicate ldp:contains when POST is successful.
  • 5.2.3.3: POSTs of LDP-NRs are accepted if the client specifies the LDP-NR interaction model. Content types for LDP-NRs must be sent in a request header.
  • 5.2.3.4: Honors LDP interaction models in HTTP Link headers. Requests without an interaction model specified are treated as requests to create an LDP-RS.
    • Interaction models are honored for all of LDP-RS, LDP-NR, LDPC, as well as Basic, Direct, and Indirect container types.
    • Requests for LDPRs are treated as LDP-RS. We read the specification as vague with respect to the clause about requested LDPR interaction model. This behavior represents our interpretation.
  • 5.2.3.5: POST requests to create an LDP-RS accept all content types supported with an RDF::Reader in the linkeddata gem (including 'text/turtle').
  • 5.2.3.6: The server relies solely on the Content-Type headers to understand the format of posted graphs. Requests without a Content-Type (or body) will fail.
  • 5.2.3.7: Relative URI resolution in RDF graphs is handled with RDF::Reader#base_uri. This is tested for Turtle input.
  • 5.2.3.8: Created resources are assigned UUID's with the container as the base URI when no Slug header is present.
  • 5.2.3.9: No constraints on graph contents are imposed.
  • 5.2.3.10: Slug headers are treated as non-negotiable requests to create a resource at [container-uri]/[Slug]. If a resource exists at that address the request will fail.
  • 5.2.3.11: Deleted resources are tombstoned and their URI's are protected from future use.
  • 5.2.3.12: When an LDP-NR is created, an LDP-RS is created at [ldp-nr-uri]/.well-known/desc. The describedBy Link header is added.
  • 5.2.3.13: Accept-Post headers are added to all responses from resources that accept post requests. Content types are added dynamically when new RDF::Readers are loaded.
  • 5.2.3.14: See: 5.2.3.5.

5.2.4 HTTP PUT

  • 5.2.4.1: Responds with 409 when attempting to write containment triples that do not already exist.
  • 5.2.4.2: See: 5.2.3.11.

5.2.5 HTTP DELETE

  • 5.2.5.1: Containment triples are removed as required when a resource is destroyed.
  • 5.2.5.2: See: 5.2.8.1.

5.2.6 HTTP HEAD

  • See: 4.2.6

5.2.7 HTTP PATCH

  • See: 4.2.7

5.2.8 HTTP OPTIONS

  • 5.2.8.1: The related LDP-RSs are created and the required Link headers are included on all requests to LDP-NRs.

5.3 Basic Container

5.3.1 General

  • 5.3.1.1: Basic Containers are treated as an alias for Container.

5.4 Direct Container

5.4.1 General

  • 5.4.1.1: DirectContainers inherit all BasicContainer behavior
  • 5.4.1.2: ldp:member is used as the default predicate in cases where the client provides none.
  • 5.4.1.3: We enforce the inclusion of exactly one ldp:membershipResource by:
    • adding the LDPDC as the ldp:membershipResource if the client does not provide one.
    • rejecting POST requests with NotAcceptable if more than one is present We allow clients to change triples including ldp:membershipResource at their own risk.
  • 5.4.1.4: The behaivor described in 5.4.1.3 applies to statements with either of ldp:hasMemberRelation and ldp:isMemberOfRelation.
  • 5.4.1.5: We implement the ldp:MemberSubject behavior as described and ignore ldp:insertedContentRelation on DirectContainers.

5.4.2 POST

  • 5.4.2.1: Triples are created as described when POSTing to a container. We allow clients to delete and replace triples at their own risk, per the MAY in this section.
    • Membership triples are added to the containers graph for both the ldp:hasMemberRelation and isMemberOfRelation cases.
    • If the Membership Resource is an LDP-NR, membership triples are added to the server-created LDP-RS (describedby, resource).
    • POST requests are rejected if the Membership Resource does not exist.

5.4.2 DELETE

  • 5.4.3.1: Triples are deleted as described in this section.

5.5 Indirect Container

5.5.1 General

  • 5.5.1.1: Indirect Containers are implemented as a subclass of Direct Containers, inheriting all of their behavior.
  • 5.5.1.2: We enforce the inclusion of exactly one ldp:insertedContentRelation by:
    • adding ldp:MemberSubject if the client does not provide one.
    • rejecting POST requests with NotAcceptable if more than one is present. We allow clients to change triples including ldp:insertedContentRelation at their own risk.

POST requests for LDP-NRs and LDP-RSs missing an expected inserted content relation, or with multiple inserted content relations, are also rejected with NotAcceptable.

5.5.2 HTTP POST

  • 5.5.2.1: ldp:contains triples are added in the same way as with Basic and Direct Containers.

Handling of Non-Normative Notes

  • 6.2.2 We supply swappable backends via the RDF::Repository abstraction. Clients may edit the resources available to LDP freely through the interfaces provided by RDF::Repository or by other means. Resources are marked as LDPRs by the presence of a specific named graph structure, which should be maintained for resources indended to be created or accessed over this server.
  • 6.2.3 After delete, we supply 410 GONE responses. Resourced deleted are treated as permanently deleted. Clients may recover them manually.
  • 6.2.5 PATCH support is implemented with the LDPatch format and with SPARQL Update.
  • 6.2.6 We do not infer content types (or LDP interaction models) from resource contents, instead relying exclusively on the headers defined and used by LDP.
  • 6.3.1 We allow clients complete control over graph contents, except where LDP requires otherwise.

Test Suite