Add support for simulating LDP container behaviour

[joachimvh]

Adds examples that show how you can create a derived resource that is the same as a standard LDP container. Also includes a bunch of cleanup and refactor changes that were caused by looking into this.

After this, you can go to http://localhost:3000 to see ldp:contains triples that were dynamically generated based on the metadata of other derived resources.

Currently we still have to manually define in the metadata config which containers should generate triples like that. We could potentially update it in the future so all containers that contain at least 1 derived resource do this.

Another disadvantage is that this only shows the containment triples of the derived resources, if there are standard resources also in this container those will not be shown any more.

Only ldp:contains triples are shown, no rdf:type or iana media type triples, but it is probably feasible to also add those as the type is determined by the URL, and for the media type we can always take turtle as derived resources are all RDF.

[phochste]

For the resource http://localhost:3000/dummy.txt I get a server error.

InternalServerError: There was a problem acquiring the filter to generate the derived resource: 
    at SparqlFilterHandler.handle (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/dist/SparqlFilterHandler.js:29:19)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async MetadataDerivationManager.deriveResource (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/dist/MetadataDerivationManager.js:112:24)
    at async RepresentationConvertingStore.getRepresentation (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/storage/RepresentationConvertingStore.js:35:32)
    at async BinarySliceResourceStore.getRepresentation (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/storage/BinarySliceResourceStore.js:25:24)
    at async GetOperationHandler.handle (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/http/ldp/GetOperationHandler.js:26:22)
    at async WacAllowHttpHandler.handle (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/server/WacAllowHttpHandler.js:36:24)
    at async ParsingHttpHandler.handleRequest (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/server/ParsingHttpHandler.js:44:24)
    at async ParsingHttpHandler.handle (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/server/ParsingHttpHandler.js:30:22)
    at async SequenceHandler.handle (/Users/hochsten/github.com/SolidLabResearch/derived-resources-component/node_modules/@solid/community-server/dist/util/handlers/SequenceHandler.js:28:26)

[phochste]

The two container examples are working, but the reason why with using a .meta is quite funky: we can select our own derived resources (!). Maybe in the README.md in the Selector second a few words can be added to explain also this usage pattern .

[joachimvh]

Every time I keep forgetting to update dummy.txt...

but the reason why with using a .meta is quite funky: we can select our own derived resources (!)

Not exactly sure what you mean with this. The input for the derived containers is not a derived resource, but the data that defines the derived resources, which is a small difference.

It might not be a bad idea that I add some more explanation to the README.

[joachimvh]

I'm not quite convinced by how templated IRI's are mentioned as "contained" in a container

I agree that those look weird, hadn't yet thought about what to do with those.

Could we consider an alternative approach in the direction of

I'll have a look. This is going to drastically complicate the SPARQL query that generates those though 😅.

Problem is that you then expose that these are not "standard" resources, and the ldp:contains triple is no longer what is expected. For some cases with a fixed set of options it might be possible to instead have it so all the available options are generated instead of exposing the templated endpoint.

[termontwouter]

Problem is that you then expose that these are not "standard" resources, and the ldp:contains triple is no longer what is expected.

But the same goes for the (non-existing) templated URI as it is implemented now. I think it is better, in the case of templated resources, to provide a format that a machine can actually detect and use to generate URI's for such resources from the template.

Another alternatives, in between the previous proposals, might be to still use the template as object:

• as a string instead of a node (then it is detectable and parseable according to URI Templates syntax);
• as a node (like any other containment triple) but with an extra triple characterizing the node as a templated resource (then derived-resources-aware clients can detect that the URI is not just to be followed) (I don't like the semantics of this though) ;
• as a node linked to the container with another predicate <> ldpext:templatedContains "{var}" (plus maybe concrete containment triples if we can generate them).

[joachimvh]

I'm currently looking at having something like <> ldp:contains [ derived:templateUrl "http://localhost/template/{var}" ].

Main problem now is that this requires a different a different SPARQL query to generate, and there is no way to merge CONSTRUCT results in a single query. So to allow both these and other resources in the same container we will need to support multiple filters to generate a single resource. Or change it so a single filter resource can contain multiple queries.

[joachimvh]

Going to merge this PR to have the new structure in the main repo and open an issue for the extra suggested behaviour above.