Context and hypermedia in all Solid responses?

[pmcb55]

For some reason I only stumbled across this fantastic blog post from Ruben last night (written nearly 4 years ago): https://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/

I totally agree with the entire premise (in fact, I personally think the embedded meta-data in responses could be very much richer than Ruben suggests here).

But my question is, how can we incorporate these ideas of embedding context and hypermedia into the responses to Solid server requests? And maybe more importantly, would it require all Solid responses to be quad-supporting serializations (i.e. no Turtle anymore!), so that we can unambiguously distinguish between the response data itself (in the default graph), and the meta-data around that data in named graphs (i.e. the context for it, and the hypermedia to 'what you can do next')...?

[RubenVerborgh]

I am still very much in favor of this idea/approach, and it works very well with API modularity (cfr. https://ruben.verborgh.org/articles/web-api-ecosystem/#principle-advertise). I've always considered the RDF document with metadata graph as the equivalent of an HTML page with navigation/sidebars: there is the main content section, and the template that is slapped around it.

However, I have discussed it with @timbl, and he was not a big fan because he wanted resources to be copyable. (So more of a Web-as-a-filesystem approach to Solid.) During that discussion, @timbl suggested that, in hindsight, the HTTP header block should actually have been a Turtle fragment (think about it, it's great). One of my concerns that prompted the discussion was that we kept on extending the HTTP headers with things such as WAC-Allow, which to me belong in the metadata section of a document (which does not require the definition of new headers, just predicates).

Now there are ways in which both visions can be aligned. One of them is through content negotiation by MIME type: if the client requests Turtle, then only send the actual data. When TriG is requested, also send the metadata graph. That guarantees copyability of the raw data. (Another difficulty here is that Solid does not talk about RDF 1.1 quad-based serializations with multiple graphs; for @timbl, the document is the graph.)

Alternatively (or even additionally), we can consider profile-based content negotiation, where there is a dedicated profile/shape for raw data, and another (default?) one for content+metadata.

So for me, going forward with a "base" Solid spec and extensions, those extensions can be advertised as metadata inside of responses.

[pmcb55]

Funny you should say:

Now there are ways in which both visions can be aligned. One of them is through content negotiation by MIME type: if the client requests Turtle, then only send the actual data. When TriG is requested, also send the metadata graph.

I was literally just about to edit the issue to include saying 'depending on the Content-Type of the request'! So yeah, I definitely agree that's one approach (and the profile-based headers are another).

But my feeling is that the core codebase needs (internally) to enforce quads everywhere to support this notion - would you agree?

[RubenVerborgh]

But my feeling is that the core codebase needs (internally) to enforce quads everywhere to support this notion - would you agree?

Yes; and this brings us also to the notion of that Messsage layer above HTTP. What if that Message layer is really a quad graph 🤯

[pmcb55]

Yep, I didn't want to ask two questions in comment, but that was exactly my next point - i.e. what if the 'user' wants to store and retrieve quads, not just triples, 'cos they have their own business-level semantic they want to apply to the named-graph component of their quads? (I actually brought up this point back at the Solid workshop in Dublin over a year ago!)

Can standardizing on specific IRI's for named graphs for context, hypermedia controls, etc. get us out of jail here - i.e. 'https://www.w3.org/ns/solid/namedGraph#context' and 'http://www.w3.org/ns/solid/namedGraph#hypermedia' or something...? Those can't clash with any user-defined named graph IRI's, and so they'd simply co-exist alongside them.

[acoburn]

This is fascinating. Using content negotiation would be an incredibly easy way to extend the basic LDP response without conflicting with ordinary LDP interactions. It would also be interesting to see how this feature (TriG and N-Quads) would interact with Prefer headers, which is an existing LDP mechanism for manipulating which data to include in the HTTP response.

[namedgraph]

You can always turn HTTP request to RDF on the fly, no need to change the specs for that: https://www.w3.org/TR/HTTP-in-RDF10/

[namedgraph]

Regarding quad semantics, allow me to bring this up again: A denotational semantics for CRUD operations on RDF datasets

[RubenVerborgh]

Major fan of hypermedia, always have been, but there is probably no consequence to the currently displayed parts of the UML diagram.