Does the ResourceStore understand conneg?

[michielbdejong]

Wondering how getRepresentation(ResourceIdentifier) : Promise<Representation> works, whether that only returns the original representation or can also convert between different RDF representations.

[RubenVerborgh]

I'm inclined to say it does not. Not pictured on the diagram yet is a ResponseGenerator, that takes a raw Representation pointer and then serializes it using a lit of serializers (cfr. #1).

However, there is a case to be made for a ResourceStore that does (limited!) content negotiation. For instance, when we have multiple on-disk representations a.ttl, a.jsonld, a.nt, we might want to just serve them. So this would be an argument for:

• getRepresentation(ResourceIdentifier, ContentPreferences) : Promise<Representation> or
• getRepresentations(ResourceIdentifier) : AsyncIterator<Representation> or even
• getRepresentation(ResourceIdentifier, ContentPreferences) : AsyncIterator<Representation>

However, it would likely not be the job of the ResourceStore to start doing conversions. That said, we could use the decorator pattern exactly for such conversions.

So all in all: to be discussed.

[RubenVerborgh]

Further context in https://github.com/inrupt/wac-ldp/issues/78#issuecomment-490848093.

[michielbdejong]

Let's try to come up with a single answer to this question and stick to it, otherwise the word 'ResourceStore' just becomes like a magic 'Cloud' icon in our diagrams (I think it already is a little bit, comparing your wording to @pmcb55's "LDP+LDN all the way down" concept?).

[pmcb55]

I'm also inclined to say it does NOT. In my mind, Ruben's example of multiple on-disk representations, i.e.:

a.ttl, a.jsonld, a.nt

... would be 3 separate, independent resources (linked together to represent 'the one thing' via the meta-data associated with each one). But that's a broader discussion I think.

[michielbdejong]

Correction, actually my question was not whether it understands conneg (as a http-level thing), but whether it understands RDF and its various representations.

[RubenVerborgh]

Let's try to come up with a single answer to this question and stick to it

There is no need for a single answer IMHO, in the sense that my answer is “the store can do forms of conneg if it wants to”. It doesn't preclude conneg on the response level, where the same TranscodingStore can be used (https://github.com/inrupt/wac-ldp/issues/78#issuecomment-490848093, I regret splitting this discussion in two).

otherwise the word 'ResourceStore' just becomes like a magic 'Cloud' icon in our diagrams

It's not, it's very clear to me: a ResourceStore gives you read/write access to representations of a resource. Might be the representation you're looking for (hurray) or not (just transcode). It will try best effort.

I'm also inclined to say it does NOT. In my mind, Ruben's example of multiple on-disk representations, i.e.:

After thinking about this for a while, there are very strong cases for giving a ResourceStore the possibility to a least try to satisfy some content preferences. When I write “content preferences”, I mean HTTP content negotiation in multiple dimensions, so not just Content-Type, but also Content-Language, and Memento-DateTime, and even upcoming dimensions such as Content-Profile (which we can use for shapes).

Correction, actually my question was not whether it understands conneg (as a http-level thing), but whether it understands RDF and its various representations.

Actually, the question is not “should the ResourceStore be the one converting between RDF formats?", but rather: are there some types of content representation preferences that are best handled by the resource store (instead of at a later stage through conversion)? And I think there are.

Actually, @pmcb55, the Trellis architecture at https://github.com/trellis-ldp/trellis/wiki/Trellis-Architecture does already incorporate date-time-based content negotiation, so that is probably a case that I will not have to argue 🙂

If I have a content-language of fr, then my triplestore could be the one fetching the French labels, instead of fetching all labels and letting the serializer drop the others.

If I have a request for a Schema.org shape (profile-based negotiation), and my triplestore has reasoning enabled, then why not get the data out in the right shape instead of having to convert it later?

If I have the JSON-LD version already on disk (in a specific framing, and framing is expensive!), then why bother reserializing it again?

These are for me strong cases to give ResourceStore an indication of the agent's representation preferences, just in case there is a quick win and it might be able to satisfy them fast. Not an obligation, just a question; at a later stage, the ResponseGenerator will be responsible for conversion in case the ResourceStore couldn't easily/quickly satisfy them.

a.ttl, a.jsonld, a.nt

... would be 3 separate, independent resources

Just want to quickly plug that this is a matter of view, not a definite matter of being. So we can consider them representations of the same resource, or consider them resources in their own right; both can be true. (Background: https://rubenverborgh.github.io/WebFundamentals/web-apis/#representations)

---

TL;DR: I propose that ResourceStore can satisfy content preferences if it wants to, but if it cannot, final conversions are done at a later stage.

Note that this does not mean that ResourceStore has to understand HTTP headers; rather, it receives parsed preferences. (“The user prefers JSON-LD [but Turtle is also fine] in English or French, and in a Schema.org shape if you have it.”)

[RubenVerborgh]

Added RepresentationPreferences to the diagram (https://github.com/RubenVerborgh/solid-server-architecture/commit/5468445f7671d2db6ce4263a314b4e6196c32e88). Can detail all of the above in a zoomed in diagram if needed.

[RubenVerborgh]

This discussion continues in depth in #10.

[RubenVerborgh]

See 159d374704ecbb4bb34d3b8cc82e38aa2b98a954.