Handling requests without an interaction model

[csarven]

How should servers handle POST, PUT, PATCH requests that not include LDP's interaction model(s) in Link?

For example:

• Reject request.
• Accept request but do not assign an interaction model.
• Normalise to an interaction model derived from Content-Type ( if not RDFSource, default to NonRDFSource or Resource?)

What may be the ramifications?

[kjetilk]

Indeed, and such resources may also include .acl #58 and .meta #63 , I suppose?

[csarven]

Perhaps acl and meta resources should have their own interaction models.

Edit: It would help to tie it with resource life cycle rules.

[kjetilk]

Perhaps acl and meta resources should have their own interaction models.

Edit: It would help to tie it with resource life cycle rules.

Yeah, in light of that there is an expectation that ldp:Resources will always be contained in a container, and .acl and .meta will not be contained, I guess we have to. To inherit most of the LDP-RS interaction model seems desireable, but I find the inheritance tree of LDP very unhelpful, we should free ourselves from that and rather think in terms of a composition of capabilities.

So, our meta resources is a composition of LDP-RS but without the containment requirement.

[csarven]

I'm not sure if there is or should have any expectation that it they are tied to LDP but I agree that they act like LDP-RS without containment baggage. Their interaction models can be described independently. We are already implicitly doing it so why not be explicit? It makes certain things simpler eg. hiding acl and meta resources from container lists: #116

[acoburn]

FWIW, Trellis treats acl and meta resources as an LDP-RS (but without any relationship to LDP containment). The main reasons are:

• The resources respond to content negotiation, just as an ordinary LDP-RS
• The resources allow GET, HEAD, PATCH, PUT and DELETE just as an ordinary LDP-RS

As an LDP-RS, responses for these resources contain LDP link headers, identifying them as an LDP-RS

[csarven]

@acoburn Thanks for sharing! Trellis' treatment seems in line with having dedicated interaction models for acl and meta resources.

How does Trellis differentiate between acl/meta resources from the rest? Would a declarative approach help to distinguish the resources?

[acoburn]

Trellis' treatment seems in line with having dedicated interaction models for acl and meta resources.

I don't have a particular opinion on this one way or the other, though I tend not to think of these as "dedicated interaction models". That is, the interaction from a client perspective is basically the same (hence, they are all LDP-RS).

How does Trellis differentiate between acl/meta resources from the rest?

Internally, every resource can be thought of as a dataset in which these different categories of data are separate partitions (named graphs). The partitions include:

• user-managed triples (trellis:PreferUserManaged)
• containment triples (ldp:PreferContainment)
• member triples (for back-ends that support LDP-DC or LDP-IC: ldp:PreferMembership)
• server-managed triples (trellis:PreferServerManaged)
• audit triples (trellis:PreferAudit)
• acl triples (trellis:PreferAccessControl)

The model is very extensible and it can support SHACL/ShEx metadata as well. It also makes it really easy to distinguish between these different categories of triples. This model also holds true for all LDP-NR, which simply point to a location where the binary byte stream can be dereferenced.

Would a declarative approach help to distinguish the resources?

Yes, that is, essentially the way it works now, though that approach is all internal to the server. It would, however, be easy to expose a distinct type for these resources. For example (I am making up an IRI here):

Link: <http://www.w3.org/ns/solid/terms#AccessControl>; rel="type"

Though any client will have (presumably) already followed the rel="acl" link header and so the client should already know that such a resource is an ACL resource. OTOH, there's no harm in being explicit.

[csarven]

rel helps but it is orthogonal to resources advertising their own affordances.

Since acl and meta don't don't live and die like regular LDP-RS, dedicated interaction models can make that distinction. While clients interact with acl and meta just like any LDP-RS, there is an agreement with the server about their lifecycle and observability.

Relying on rel enforces that both server and client must observe at least two resources ie. original resource; related acl and meta; and affected resources - at the same time in order to act on them eg. observability in containers.

Would Trellis' use of trellis:PreferAccessControl be similar to the hypothetical solid:AccessControl interaction model?

[acoburn]

Relying on rel enforces that both server and client must observe at least two resources ie. original resource; related acl and meta; and affected resources - at the same time in order to act on them eg. observability in containers.

This is a really good point. A possibly related piece of information is that the rel="description" and rel="describedby" headers for an LDP-NR and its associated description forms a bidirectional relationship between the two resource URLs. Perhaps something similar could be done with ACL resources: rel="acl" and rel="isAclFor" (or something like that -- surely there is a better name), which would allow ACL resources to identify themselves much more clearly to a client.

Would Trellis' use of trellis:PreferAccessControl be similar to the hypothetical solid:AccessControl interaction model?

Yes -- for these internal named graph IRIs, I reused existing identifiers where appropriate (ldp:PreferContainment, etc), and invented application-specific ones where necessary. If other, more appropriate, IRIs were available (e.g. published through a Solid-specific vocab), I would gladly use those instead.