Handling resources and updates with conflicting interaction models

[kjetilk]

We need to figure out what we do with resources that do not follow the same interaction models.

For example, if we have a LDP-RS (i.e. an RDF source), and somebody tries to PUT and image (aka LDP-NR) to replace it.

In Solid, it appears that we have at least four types of resources: Containers, more specifically LDP-BC, non-RDF sources which are contained in containers, RDF sources that are contained (aka "the resource"), and RDF resources that are not contained, e.g. .acls. In addition, HTML can be both RDF resources and non-RDF resources.

Since #35 implies that containers end with a /, it means that containers are distinct from the other resources, and so none of them can change type, except possibly for the HTML resources, that may or may not contain RDF which fully represents the state.

The formal isa-relationship implied by the resource types of LDP does not seem to serve us well.

In addition, representations may be incompatible with each other, a song and an image may not be representations of the same resource, but that's not a new problem.

[csarven]

We need to figure out what we do with resources that do not follow the same interaction models.

re updating resources, given that LDP servers should not re-use URIs (re AWWW), it can follow that changing:

• LDPR to another LDP interaction model is allowed.
• LDP-RS and LDP-NR to LDPR should not be allowed.
• LDP-RS to LDP-NR and vice versa should not be allowed.
• LDPC to LDP-BC, LDP-DC or LDP-IC should be allowed.
• LDP-BC, LDP-DC, LDP-IC should not be allowed.
• removing an interaction model should not be allowed.

Less formally or simply: changing can only specialise.

RDF resources that are not contained

They could have their own interaction models eg #105 (comment)

HTML can be both RDF resources and non-RDF resources.

Since #35 implies that containers end with a /, it means that containers are distinct from the other resources, and so none of them can change type, except possibly for the HTML resources, that may or may not contain RDF which fully represents the state.

Given that an LDPC is an RDF source, it simply requires that its representations encode server-managed triples. Once a resource is deemed to be an RDF source, the underlying RDF graph holds the intended semantics of the resource - we've discussed this.

In addition, representations may be incompatible with each other, a song and an image may not be representations of the same resource, but that's not a new problem.

If so, why do we need to address that?

[kjetilk]

* LDPR to another LDP interaction model is allowed.

No, because it depends on the URI, if the URI ends with a /, it is an LDP-C, and so the rest of the rules constrains it.

[csarven]

No, because it depends on the URI, if the URI ends with a /, it is an LDP-C, and so the rest of the rules constrains it.

True, especially if LDPR is the only type that's used.

We could partly prevent that from happening if a pseduo-algo like the following is used for requests to create:

• / and no interaction model, success? (server adds LDPC, LDP-BC? and/or Handling requests without an interaction model #105 )
• / and LDPR, success? (server adds LDP-RS, LDPC, LDP-BC?)
• / and LDP-RS, success? (server adds LDPC, LDP-BC?)
• / and LDPC, success? (server adds LDP-BC?)
• / and LDP-NR, fail?

it could mean that where applicable, LDPR is always accompanied with more specific interaction models.

[kjetilk]

What I'm trying to get at is that the model of "more specific interaction models" is the true problem here. There is some use for that idea, but as a starting point for the design, it is fundamentally flawed.

[csarven]

I don't see a flaw per se but good discussion point. Here is one take:

As previously agreed, by examining a URI, it is possible to determine the following:

• Segment ending with / entails the resource will behave like a LDP-RS, LDPC, LDP-BC.
• Segment ending without / entails the resource will behave like a LDPR.

By examining a resource's representation, we know whether it will be handled as a LDP-RS or LDP-NR. Moreover, we can also determine specific kinds of LDP-RSs beyond a LDP-BC eg. acl, meta resources determined by the message semantics.

At this juncture, stating the interaction model in the requests and responses is technically redundant. This is also a bit of a shift from explicit to implicit.

In the interest of striving for orthogonality to some extent, the Solid spec could be designed in a way that would leave LDP as optional. There is a catch of course. The Solid spec will need to prescribe requirements that will reiterate quite a bit of LDP. I'm not certain if this would be a worthwhile exercise, but the expected spec (so far) is already committed to extending or clarifying LDP, so it is feasible. It needs to be clear about the lifecycle of different kinds of resources without resorting to LDP so that implementations while conforming to the Solid spec could potentially use something other than LDP (eg. LDT?)

Having said that, the path of least resistance is to play along with LDP and extend where necessary - which is for the most part what we've been doing to date.

[kjetilk]

I don't see a flaw per se but good discussion point. Here is one take:

As previously agreed, by examining a URI, it is possible to determine the following:

* Segment ending with `/` entails the resource will behave like a LDP-RS, LDPC, LDP-BC.

* Segment ending without `/` entails the resource will behave like a LDPR.

By examining a resource's representation, we know whether it will be handled as a LDP-RS or LDP-NR.

Say media type, and I'm with you! :-)

There is the case of media types with embedded RDF (e.g. HTML+RDFa), though, which falls between or in both those categories.

Moreover, we can also determine specific kinds of LDP-RSs beyond a LDP-BC eg. acl, meta resources determined by the message semantics.

At this juncture, stating the interaction model in the requests and responses is technically redundant. This is also a bit of a shift from explicit to implicit.

Yup, it is.

In the interest of striving for orthogonality to some extent, the Solid spec could be designed in a way that would leave LDP as optional. There is a catch of course. The Solid spec will need to prescribe requirements that will reiterate quite a bit of LDP. I'm not certain if this would be a worthwhile exercise,

Indeed, I agree it is not. What is worthwhile, I think, is to explore the borderlines where adhering to LDP causes friction with Solid as understood by current implementation(s), we are basically writing up a specification for a system that already exists. From there, we can take the pieces that fit, which is most of it, and go with that.

I think we could go a long way with checking for internal consistency, e.g. a request that declares a container interaction model but where the request URI does not end with a / is internally inconsistent and should not be allowed; and that we don't look at the formal isa relationships of LDP as set in stone.

[csarven]

Say media type, and I'm with you! :-)

media type.

There is the case of media types with embedded RDF (e.g. HTML+RDFa), though, which falls between or in both those categories.

Excluding / (the LDPC-like) case - as that automatically entails an RDF source - nothing needs to be done for LDP-NR- and LDP-RS-like case. Since the server can determine if a representation is RDF- bearing, it can also decide if it can and wants to provide representations with different serialisations. Similarly, client can decide if it can and wants to parse the representation to potentially get an RDF graph, in addition to handling it without.

I think we could go a long way with checking for internal consistency, e.g. a request that declares a container interaction model but where the request URI does not end with a / is internally inconsistent and should not be allowed; and that we don't look at the formal isa relationships of LDP as set in stone.

Agreed. By the way, that example and possible solution is precisely what would be required based on one of the warnings I've raised in #35 (comment):

The semantics encoded in the URI string becomes most authoritative and overrides the information in the representation metadata and data.

[kjetilk]

Say media type, and I'm with you! :-)

media type.

Thank you!

There is the case of media types with embedded RDF (e.g. HTML+RDFa), though, which falls between or in both those categories.

Excluding / (the LDPC-like) case - as that automatically entails an RDF source - nothing needs to be done for LDP-NR- and LDP-RS-like case. Since the server can determine if a representation is RDF- bearing, it can also decide if it can and wants to provide representations with different serialisations. Similarly, client can decide if it can and wants to parse the representation to potentially get an RDF graph, in addition to handling it without.

Yup. It is just to say, LDP-NR and LDP-RS are not mutually exclusive classes.

I think we could go a long way with checking for internal consistency, e.g. a request that declares a container interaction model but where the request URI does not end with a / is internally inconsistent and should not be allowed; and that we don't look at the formal isa relationships of LDP as set in stone.

Agreed. By the way, that example and possible solution is precisely what would be required based on one of the warnings I've raised in #35 (comment):

The semantics encoded in the URI string becomes most authoritative and overrides the information in the representation metadata and data.

Right, I see. I interpreted that comment to mean that the server would accept inconsistent requests and try to make the best of it, but in the general case, that's not what I think it should do, it should reject inconsistent requests. So, I tend to think it is not that it overrides information in data and metadata, it demands consistency, which is not quite the same as override :-)

[csarven]

Well, consistency is checked with the authoritative truth. So, if URI is ultimately making the call, then we need to make decisions based off that - that's all the bullet point in a comment meant and to investigate further (as opposed to fleshing out the whole thing). I agree that failing as soon as soon there is a mismatch detected makes sense.

[kjetilk]

I think of it as just

if (requestUri.endsWith('/') && interactionModel.is('ldp:Container') && ...) {
  do.stuff()
} else {
  return 400
}

if you get the idea. :-) Just conjuction, not any one of them being authoritative.

Anyway, this is clearly under discussion now, so I'll put it on the project board. :-)

[RubenVerborgh]

Resolution in the meeting of 2019-12-04 regarding the case of "no interaction model": the server will determine one using heuristics to be specified in #128.

[csarven]

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

[csarven]

This issue was initially approached from the perspective of LDP's interaction models. It was resolved in #128 (comment) without being tied to LDP's interaction models.

#157 explained URI Persistence non-normatively ( https://solidproject.org/TR/protocol#uri-persistence ).

There can be normative text about server's response to client request to update RDF Source into non-RDF Source or vice versa. Similar to capturing #121 (comment) eg. "LDP-RS to LDP-NR and vice versa should not be allowed."

Servers MUST NOT allow clients to change a resource's type after its creation; from an RDF Source to non-RDF Source and vice versa; if the server receives such a request, it MUST respond with a 415 status code.

Are there use cases to allow that change? If so, we may want to use SHOULD NOT instead of MUST NOT. Or possibly don't say anything?

[csarven]

Retracting the normative text preventing "change". It is not particularly meaningful in context of Solid. It's implementation may end up being similar to LDP's interaction model. I suggest that we don't introduce this restriction. It would allow servers to have RDF and non-RDF representations to be available for the same resource, if so desired. Fine by me.