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.

[kjetilk]

FWIW, the most recent stuff I've committed to the test suite solid-contrib/test-suite#56 does LDP-NR and LDP-RS interactions very vanilla, i.e. no Link header, and it mostly Just Works[tm] with some caveats. I think there is an expectation it isn't strictly necessary to be explicit about the interaction model, but that we should ensure consistency.

[kjetilk]

Continuing with tests, I found that NSS will add a directory with the POST+Slug route without specifying interaction model, but it will not add a .meta with the triples from the body.

[csarven]

rel="isAclFor"

If I understand correctly, I have some doubt that will work neatly because an ACL can be associated to multiple resources. Hence, requiring multiple relations in the Link header referring to all resources using the same ACL.

[kjetilk]

We had a short discussion about this, in the light of that NSS mostly does the Right Thing without the interaction model specified. Moreover, since ending with / implies container in the Solid context (#35), and that the server determines what is an ACL (#31) client supplied interaction model is redundant for these resources.

This suggest to me that we shouldn't do anything dramatic if interaction model lacks, we have several pieces of information that will tell us what kind of resource it is without relying on the interaction model HTTP Link header.

[csarven]

I've mapped segment ending with and without /and LDP's interaction models in #121 (comment) (including requests without the model specified) and how different kinds of LDPR behave in #121 (comment)

The question is, should we prescribe or describe that.

Aside: It is worthwhile to consider how existing LDP implementations can transition by implementing the Solid spec. Using the interaction models in a uniform way can help with that. Solid applications can interact with a class of LDP servers.

[RubenVerborgh]

Resolution: in the meeting of 2019-12-04, we decided that, upon receiving a request without interaction model, the server will be determine the model using a specified set of heuristics to be specified in #128.

[csarven]

Closing this issue based on #128 (comment) . Feedback welcome.