At this moment, IRIs for the event are not dereferenceable as they are build as follows: namednode iri of the dcat entity + # + timestamp

I instead propose to do a relative IRI: #dataset/timestamp. That way, the IRI will be relative to the current page and will be dereferenceable, successfully creating a dereferenceable IRI for the activity

Let’s split off the logic for the Dump to Feeds based on a Shape Template. It should become a processor within the RDF Connect framework

This repository should then contain the configurations to make different DCAT dumps work.

• As argument, it needs to take
  • a NodeShape IRI
  • optionally an URL to the ShapesGraph (which is going to default to the URL the NodeShape dereferences to) -- From that URL, we will also need to follow owl:imports recursively
  • An RDFStore containing a new iteration of the dump
  • A list of focus nodes it needs to start from
• When used as a library in the RDF Connect framework, it must write the stream the RDF Connect way
• We should ensure this can then work for any kind of dumps scenario

For big files (500MB), currently this library requires more than 16GB or RAM. This is most probably due to the indexing mechanism of the N3.Store. We should look into configuring our own index based on RDF Stores by Ruben Taelman

https://github.com/rubensworks/rdf-stores.js?tab=readme-ov-file#index-combinations

Add tests with entities containing blank nodes in various positions:

• Will test whether canonization works as expected
• Will test whether we gracefully warn about problems when using blank nodes for standalone entities

1. Use RDF-JS types instead of N3 types (note to self: always to that by default)
2. Add the console log into the bin, and make stream configurable
3. Make the shape template configurable
4. Allow to configure the targets for the “standalone” entities so that this script can be used for any kind of data dumps to LDES pipeline.