Which LDP features are required by Solid

[acoburn]

Section 2.2 of the Solid specification requires (MUST) conformance with the LDP specification. The LDP specification, however, lists many features as optional.

LDP requires that a server support GET, HEAD and OPTIONS.

At what level of support does a Solid server implementation need to implement POST, PUT, DELETE and PATCH? It is worth noting that, via OPTIONS, a client can easily discover which methods a server supports for a given resource (via the Allow response header). It is also worth noting that PATCH is, effectively, an optimization of PUT.

[RubenVerborgh]

My suggestion is to make POST, PUT, DELETE, and PATCH all MUST for Solid; except that of course a server is free to only offer read-only resources, in which case it would not need to support them.

I would also make PATCH a MUST because of concurrent editing use cases.

[csarven]

Need to be clear on "support". Checking for support can be a grey area in that if MUST is given, server's capability needs to be essentially testable. Whether they offer resources as read-only is a separate case and we can incorporate that in the test. For example, the test can offer a check against read-only resources, and when tested as such, all MUSTs would be expected to return a 405 and so it will pass the test, and fail otherwise.

[csarven]

Just so that we document some reasons: an overarching reason as to why methods like POST, PUT, DELETE and PATCH should be required (at some level) for servers to support is that the writing - creating, deleting, updating - capability is central to the Solid ecosystem.

We need the servers at MUST to enable an even ground for clients. I don't think SHOULD will cut it.

[csarven]

I tentatively suggest the following which extends LDP:

Generally:

GET: ...
HEAD: ...
OPTIONS: ...
POST: creating, appending, containment management
PUT: creating, replacing
PATCH: creating, updating
DELETE: remove, containment management

Specifically:

Intention for server-side containment management SHOULD be communicated through POST and DELETE. PUT and PATCH SHOULD NOT effect containment management.

Servers MAY use both the Slug and the Link header values in POST requests to determine hints for containment management. In the following example, the server uses the slashes in Slug as a separator for nested containers based on the interaction model(s) as specified in the Link header.

POST /
Slug: foo/bar/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/bar/

is equivalent to:

POST /
Slug: foo/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/

POST /foo/
Slug: bar/
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

Location: http://example.org/foo/bar/

GET /foo/

Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"

<>
  ldp:contains <http://example.org/foo/bar/> .

Clients intending to create both the resource and containment triples for a URI eg. http://example.org/foo/bar/baz should:

1. POST to create container(s) eg. http://example.org/foo/ contains http://example.org/foo/bar/
2. POST to create resource in container eg. http://example.org/foo/bar/ contains http://example.org/foo/bar/baz

Second step as example:

POST /foo/bar/
Slug: baz
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"

Location: http://example.org/foo/bar/baz

[dmitrizagidulin]

Intention for server-side containment management SHOULD be communicated through POST and DELETE. PUT and PATCH SHOULD NOT effect containment management.

I think the terminology is slightly confusing. Container management is something solely done by the server, and not a concern for the client (not even communicating an intention). And clients should be able to create/modify/delete resources via the usual verbs - PUT, POST, DELETE.

[csarven]

I think the terminology is slightly confusing. Container management is something solely done by the server, and not a concern for the client (not even communicating an intention).

Taking LDP's "server-managed triples" as given. The attempt was to clarify the affordances of those methods in LDP. Is this more clear:

Clients SHOULD use POST and DELETE to apply LDP's interaction models on resources. Servers SHOULD NOT allow PUT and PATCH to effect server-managed triples.

Re:

not even communicating an intention

I understand the context in which you mean that but I was going with text like the following or other client hints:

LDP servers that successfully create a resource from a RDF representation in the request entity body MUST honor the client's requested interaction model(s)

Clients certainly make their intentions clear to the server. They acknowledge the purpose and effects of using the interaction models eg. POST to a LDPC will result in...

[TallTed]

@csarven - How about --

Servers SHOULD NOT allow triples within PUT and PATCH payloads to affect server-managed triples.

(Side note: affect, not effect.)

[RubenVerborgh]

We'd need a definition of "server-managed triples" (and maybe a different term).

Also "should not allow" is vague: should they reject it? Or ignore it?

Let's be very specific.