GIPOD has an LDES and Basic LDES server is being deprecated in favor of LDES Solid Server

[pietercolpaert]

Hi Sander,

Awesome that you’re getting started with LDES!

Couple of links you might want to find out about today rather than tomorrow:

• GIPOD is currently working on an LDES in production: https://private-api.gipod.test-vlaanderen.be/api/v1/ldes/mobility-hindrances - still contains a couple of bugs, but will be resolved asap
• The Basic LDES server is a very low quality prototype. Check out https://github.com/treecg/ldes-solid-server for our currently maintained codebase that should be better maintained and better designed

[sandervd]

Hi Pieter,

Thanks! I was rather confused by the basic server (I couldn't figure out where the ldes:EventStream is supposed to be created for instance).

I'll certainly have a look at the solid implementation. I was also thinking of some other potentially interesting components for the ecosystem:

• A Kafka Connect LDES Source/Sink, this could be a really reusable component for robust ingestion/publication I was thinking to have the sink write files to disk, so they could be published by a static webserver. This could be done in a very memory efficient way, even with versioning/retention policies (where the state needs to be communicated through the tree:member).
• An Websocket based implementation for publishing/consuming LDES streams.
• A Kafka Stream RML application. This would allow for RDFizing events 'in stream'. This would of course only work for simple entities, as mapper would only have the event being processed as input. Could be a standard component, taking an RML file as config. -... I would certainly love to discuss some ideas with you!

Anyway, I have no use for the GIPOD data as such at the moment, just playing a bit :)

[pietercolpaert]

Hi Sander,

All sounds great! We are working on a connector system as well to create lineage across message broker technologies, and being able to chain different processors. Relevant links for that:

• Our metadata specification we’re building to keep the provenance and DCAT metadata across processors: https://w3id.org/sds/specification
• The connectors repo with connectors to for example Kafka we’re prototyping: https://github.com/treecg/connectors - this should allow you to build processors in javascript that read from a certain channel technology and write it back to the same or another channel technology, or even write it to a store such as mongodb or an NGSI-LD broker.