This wiki has been archived and is now read-only.


From Linked Data Platform
Jump to: navigation, search


Informal list of what's not required by the LDP spec that clients might reasonably expect LDP to tell them how to introspect. Note that I intentionally cast what is likely a too-wide net here, by flagging all 2119 keywords aside from MUST for consideration.

Table contents are based on a mid-March snapshot of the spec. While that makes it somewhat stale, the basic issues should not change much so it should be useful to deal with overall approach issues.

I refrained from rendering explicit the following options that exist in many/all cases:

  • Remain silent
  • Note that HTTP defines how (usually: try it and then look for a specific status code)
  • Explicitly declare it as undefined, out of scope, implementation-specific, or similar

Location Affordance What spec says today about introspection What part of HTTP/RDF covers it,
if any
Alternatives identified
(if not yet spec'd out)
4.1.3 Membership includes both LDPRs and non-LDPRs Is there a genuine need for a client to introspect this?
Representations offered: Turtle required, others optional. Might vary based on Method too, e.g. PATCH formats and POST requests. content negotiation, 406 Not Acceptable
LDPRs CRUD'ed using methods not defined in LDP; ditto LDPC members HTTP method definitions, side effects of GET, HEAD
4.1.12 Entity tags may be strong or weak etags; weak if W/ prefix present
PUT, PATCH, POST, DELETE supported (LDPRs and LDPCs) 4.6.2 HEAD+Allow Allow, Options+Allow, 405 Method Not Allowed
4.4.2 Does server require if-match always "SHOULD require if-match + etags to detect collisions" status code: 304 Not Modified, 412 Precondition Failed, but no obvious way to detect required-ness of conditional requests as a blanket
Create LDPR using PUT, PATCH, POST; the "create" semantic potentially being separate from the method implementation, perhaps by media type (think about binary members) Could we re-use AtomPub app:accept ?
Update LDPR using PUT, PATCH w/o knowing detailed constraints. What constitutes detailed constraints?
4.5.2 Delete may have side effects generally true except for GET/HEAD HTTP method definitions, side effects of GET, HEAD
5.2.3/5.2.4 Choice of membership subject default LDPC's canonical URI, or object of ldp:membershipSubject
5.2.3/5.2.5 Choice of membership predicate default rdfs:member, or object of ldp:membershipPredicate
5.3.2 Access to LDPC's non-membership triples try ?non-member-properties, process redirects
5.3.3 LDPC supports client-initiated paging try ?firstPage, process redirects
HEAD and look for Link header in response
HTTP Link header rel=first LDPC server-initiated paging should 303-redirect 303 See Other which resource is being paged should have rdf:type=ldp:Page, ldp:pageOf=container's URL
5.3.7 Does LDPC support *ordered* paging, given that it supports paging at all detectable after the fact(?) via ldp:containerSortPredicates (gap: what subject?)
5.4.3 LDPC supports creation of non-RDF resources? which? assuming this is based on media type, would be subset of the "representations offered" row.
5.4.5 Does create 201 response include representation should not (post 201) should contain an entity which describes the status of the request and refers to the new resource
5.4.7 Create content sniffing may; should use request's content-type
5.5.1 LDPC PUT, PATCH updates membership should not (PUT), silent (PATCH)
5.5.2 LDPC PUT, PATCH updates NON-membership may (PUT), preferred (PATCH)
5.6.x DELETE LDPC deletes members too?
  • Look at <LDPC,rdf:type,ldp:xxx>
  • Look at <LDPC,ldp:xxx,?o>