Create a Mashlib configuration that embeds the Turtle representation into the HTML

[RubenVerborgh]

Currently, asking for HTML with the Mashlib configuration will lead to a constant HTML file:

Recipes/mashlib/config-mashlib.json

Lines 43 to 58 in 64595db

	{
	"comment": "Serve Databrowser as default representation",
	"@id": "urn:solid-server:default:DefaultUiConverter",
	"@type": "ConstantConverter",
	"contentType": "text/html",
	"filePath": "./node_modules/mashlib/dist/databrowser.html",
	"options_container": true,
	"options_document": true,
	"options_minQuality": 1,
	"options_disabledMediaRanges": [
	"image/*",
	"application/pdf"
	]
	},
	{

@timbl has suggested an experiment in which we embed the Turtle representation of a resource into the Mashlib HTML.

Steps:

1. Create an EJS or Handlebars template where the Mashlib HTML has a placeholder for Turtle
2. Fill the Turtle placeholder with the incoming stream (which will be Turtle)
3. Wire up this new template, indicating that it converts text/turtle into text/html

Bonus: for non-RDF resources, keep on serving the static Mashlib HTML.

Original context: https://gitter.im/solid/solidos?at=630e32103a42316d33c864f7

[joachimvh]

Bonus: for non-RDF resources, keep on serving the static Mashlib HTML.

ConstantConverter should be a TypedRepresentationConverter instead of just a RepresentationConverter. Shouldn't be an issue, it just preceded that type. It should return a weight of for example 0.9 for HTML output.

We would need a new TurtleToHtmlConverter or something, which returns 1.0 for HTML output, if the input is turtle.

Both of these should be put in a new ChainedConverter, which should be the new instance of urn:solid-server:default:DefaultUiConverter.

Extra nice bonus would be if the HTML output could be streaming, but that would probably require a new templating engine or a custom solution.

[timbl]

DataIIslandN3ToHTMLConverter maybe

[timbl]

The Data Island style is what is being tested.

[RubenVerborgh]

We would need a new TurtleToHtmlConverter or something, which returns 1.0 for HTML output, if the input is turtle.

I wonder if we cannot just adjust the existing HTML templating engine into an (optional) convertor. The convertor input would be "any text stream", such that the HTML templating engine can take a text (plus content-type metadata) and process it with the rest of the parameters.

[joachimvh]

I wonder if we cannot just adjust the existing HTML templating engine into an (optional) convertor.

I would not overload the templating engine itself with extra functionality but wrap something around it, which is what that TurtleToHtmlConverter would pretty much be. We could generalize it to a TextToHtmlConverter that converts any text/* format to HTML this way. Note that we can already chain template engines into a bigger engine. So one template engine converts the text stream into the relevant HTML block, and the second one then embeds it into whatever the main template is. This is how we generate the HTML for all the IDP related pages (as we have 1 main template, and one specific for each page).

[kidehen]

@RubenVerborgh,

I would encourage embedding of both RDF-Turtle and JSON-LD, or at the very least JSON-LD.

Why?
JSON-LD is now broadly supported by content publishers and structured data centric user-agents.

/cc @timbl

[RubenVerborgh]

Definitely agree with that, @kidehen. Small practicality is that we don't have a MIME tyoe for clients to request the different ones, but profiles could do