LDP Implementation Report (2014-03-11)
Implementation Report based on the WD-ldp-20140311.
General Implementation Restrictions
- Identifiers
- trailing slash is ignored (removed) for URI generation.
thus http://example.com/foo and http://example.com/foo/ are treated as identic. - query part of an URL will never be used as part of a URI.
query parameters might be used for some LDP operations such as non-membership triples (tbd) - resources with fragments can't be addressed directly, but can be accessed via their container (URL without fragment)
- trailing slash is ignored (removed) for URI generation.
- Storage
- internally every LDPR will be stored in its own (Sesame) context (as could be interpreted from sec 5.2.3.4)
- that would allow us to extend the Resource concept beyond the common understanding in triplestores (just one level of outgoing triples)
- Paging and Sorting is not supported
Anyway the WG has resolved (Feb 17, 2014) to move out paging and ordering into a separate spec: 2014-02-17#r5 - ETags for LDP-RS are weak and soley based on the
dcterms:modified
value, while ETags for LDP-NR are based on the md5sum of the file content. - We will provide support to the full LDP hierarchy (discussion on the mailing-list).
- Our interpretation of Sec. 5.2.3.12 implements that POST of content types not managed by the platform (i.e., not suitable Rio parser registered) adds a LDP-RS as member of the container, linking (
dct:hasFormat
/dct:isFormatOf
) to the actual LDP-NR (URI is build by appending the file extension according the content type)
- Our interpretation of Sec. 5.2.3.12 implements that POST of content types not managed by the platform (i.e., not suitable Rio parser registered) adds a LDP-RS as member of the container, linking (
- Sec. 5.2.3.12 (
rel='describedby'
-Link) will be fulfilled by pointing to this page.
Link: <http://wiki.apache.org/marmotta/LDPImplementationReport/2014-03-11>; rel="describedby"
- Creating new resources using
HTTP PUT
is not allowed (Sec. 4.2.4, Sec. 5.2.4) - For the time beeing, only LDP-BCs are supported
- PATCH accepts application/rdf-patch only
Patches with the predicateldp:contains
will result in aHTTP 409 Conflict
4 LDPR
4.2 Resource
- 4.2.1.1 HTTP/1.1 conforms
- 4.2.1.2 Resource mixture: supported
- 4.2.1.3 ETag: conforms (weak tags for LDP-RS, strong for LDP-NR)
- 4.2.1.4 Link type ldp:Resource: conforms
- 4.2.1.5 base-URI: conforms
- 4.2.1.6 Link describedby conforms: link to implementation report
- 4.2.2 GET supported
- 4.2.2.1 GET to LDPR supported
- 4.2.2.2 LDP-R Headers: see 4.2.8
- 4.2.3 POST supported (will turn LDPR into LDPC)
- 4.2.4 PUT work-in-progress
- 4.2.5 DELETE supported
- 4.2.6 HEAD supported
- 4.2.6.1 HEAD to LDPR supported
- 4.2.7 PATCH supported
- 4.2.7.1 Accept-Patch: application/rdf-patch supported
- 4.2.8 OPTIONS supported
- 4.2.8.1 OPTIONS to LDPR supported
- 4.2.8.2 Allow Header: conforms
4.3 RDF Source
- 4.3.1.1 ldp:!RDFSource is materialized: conforms
- 4.3.1.2 ldp:!Resource and specific type: conforms
- 4.3.1.3 (pending)
- 4.3.1.4 RDF-representation: supported
- 4.3.1.5 Reuse Vocabularies: RDF, DCTERMS, LDP: conforms
- 4.3.1.6 Reuse Predicates: conforms Overlapping with 4.3.1.5?
- 4.3.1.7 multiple rdf:type: supported
- 4.3.1.8 changing rdf:type: supported
- 4.3.1.9 open predicates: supported
- 4.3.1.10 no inferrence required by client: conforms
- 4.3.1.11 Client Requirement: does not apply
- 4.3.1.12 Prefer Header: not-supported
- 4.3.1.13 Client Requirement: does not apply
- 4.3.1.14 Client Requirement: does not apply
- 4.3.2 GET supported
- 4.3.2.1 text/turtle: supported
4.4 Non-RDF Source
- 4.4.1.1 ldp:NonRDFSource is materialized: conforms
5 LDPC
5.2 Container
- 5.2.1.1 ldp:Container and ldp:RDFSource are materialized: conforms
- 5.2.1.2 only ldp:BasicContainer supported: conforms
- 5.2.1.3 RDF-Containers are not used: conforms
- 5.2.1.4 Advertise LDPC type: conforms
- 5.2.1.5 Prefer Header: not yet supported
- 5.2.2 GET supported
- 5.2.3 POST supported
- 5.2.3.1 add member resources by POST: supported (LDPC created on demand)
- 5.2.3.2 ldp:contains (to binary if present): conforms
- 5.2.3.3 LDP-NR: supported
- 5.2.3.4 LDP Interaction Model: work-in-progress
- 5.2.3.5 text/turtle supported
- 5.2.3.6 Content-Type Consideration: supported
- 5.2.3.7 base-URI for parsing is the created Resource: conforms
- 5.2.3.8 UUID for resource names: conforms
- 5.2.3.9 No specific constraints on creation: conforms
- 5.2.3.10 Slug: Header supported: conforms
- 5.2.3.11 Do not reuse URIs: (pending)
- 5.2.3.12 LDP-NR and associated LDP-SR are created: conforms
- 5.2.3.13 Accept-Post is provided on OPTIONS: conforms
- 5.2.4 PUT not yet supported
- 5.2.5 DELETE supported
- 5.2.5.1 delete containment triples: conforms
- 5.2.5.2 delete associated LDP-RS for LDP-NR: conforms
- 5.2.6 HEAD supported
- 5.2.7 PATCH supported
- 5.2.7.1 PATCH method supported: conforms
- 5.2.8 OPTIONS
- 5.2.8.1 Link with type "describedby" is provided for LDP-NR: conforms
5.3 BasicContainer
- 5.3.1.1 ldp:Container is materialized: conforms
5.4 DirectContainer
ldp:DirectContainers are not yet supported.
5.5 IndirectContainer
ldp:IndirectContainers are not yet supported.
6 Notable information from normative references
6.1 Architecture
- 6.1.1 Only LDP-BC supported, so does not apply.
- 6.1.2 see 5.2.3.11, clarification pending
6.2 HTTP/1.1
- 6.2.1 Support other RDF representations: Default Sesame Parser/Serializer Formats supported
- 6.2.2 SPARQL 1.1 supported
- 6.2.3 404 returned after DELETE
- 6.2.4 All triples under server-control where the Resource occurs as subject or object are deleted, further clarification pending
- 6.2.5 PATCH (application/rdf-patch) supported
- 6.2.6 not supported
6.3 RDF
- 6.3.1 LDPR can contain arbitrary triples
- 6.3.2 Containment not inlined
- 6.3.3 arbitrary number of rdf:type is allowed
7 HTTP Headers
7.1 Accept-Post Header
see 5.2.3.13
7.2 Prefer Header
see 4.3.1.12 and 5.2.1.5
8 Security
HTTP Basic Auth is supported
Open Issues and Questions
Missing Things
- Update LDP Ontology http://www.w3.org/ns/ldp# with the terms missing from the Spec:
- ldp:BasicContainer
- ldp:contains
- ldp:DirectContainer
- ldp:hasMemberRelation
- ldp:IndirectContainer
- ldp:insertedContentRelation
- ldp:isMemberOfRelation
- ldp:member
- ldp:membershipResource
- ldp:MemberSubject
- ldp:PreferContainment
- ldp:PreferEmptyContainer
- ldp:PreferMembership
- ldp:RDFSource
- Add ldp:NonRdfResource to the Spec. and LDP-Ontology
(URI is never explicitly used in the Spec) - Extra Link: Headers on Requests to LDP-R
- LDP-NR: Link with href of the corresponding RDF-RS with type "meta"
- LDP-RS: Link with href of the corresponding RDF-NR with type "content" (if present)
Clarifications
- 5.2.3.11 Is using an URI that was previously DELETEd considered "re-using"? (see also 6.1.2)
- 5.2.3.12 (also 5.2.8.1) Link to the LDP-RS rel should be "meta" or "describedby"? (ISSUE-15)
- 5.2.3.12 Is the LDP-RS also "ldp:contains" by the LDPC?
- 4.2.5 When an LDP-RS is deleted and the LDP-RS is associated with an LDP-NR, should the LDP-NR be deleted too? (see also 5.2.5.2)
- 5.2.7.1 (also 4.2.7) Is it allowed for the LDP Server to restrict the properties changed by a PATCH request (analoguous to 4.2.4.1)
- 6.2.4 Is it allowed to modify properties of a LDPC where a LDPR was deleted from, e.g. dct:modified?