Add timeseries store backend to better support IoT use cases

[Falx]

Pitch

IoT is and still remains an important topic on the internet. It is typically related to high frequency timeseries data. It would thus be interesting to have a backend solution that is tailored to storing timeseries data. When picking the appropriate backend solutions for this, some important optimizations can be performed because of how timeseries are typically structured.

Desired solution

A ResourceStore backend implementation with support for timeseries data.

Acceptance criteria

• CSS can store high frequent timeseries in a specialized backend store.
• Configuration files are available to start the CSS with this specialized backend store.

Pointers

• We know of backend stores that can handle these timeseries like InfluxDB and ClickHouse. This might have be good candidates, they are however external dependencies that have to be spun up separately.

[pietercolpaert]

This is related to #27 I believe

[jeswr]

For what it's worth, I believe that such an implementation should be able to viewed and edited as if it were an RDF (or RDF* depending on the data you are storing?) document using some kind of wrapper - whilst also maintaining existing API access of the chosen backend for performance.

This means that one can still execute a SPARQL/SPARQL query over the data from something like Comunica ([once SPARQL it is fully implemented](https://github.com/comunica/comunica/issues/594)) and thus more applications will be able to interface with the data upfront.

[pietercolpaert]

:+1: @jeswr - I think the most difficult about this issue is

1. Defining the hypermedia so that Comunica can automatically find this index and use it when it’s available, but other indexes may be good alternatives and apps should keep working even if there is no timeseries-based back-end
2. Keeping all indexes in-sync: do we work with eventual consistency, or will we lock reading from derived views until a POST/PUT/PATCH request is fully processed?

[gibsonf1]

We (Grapmetrix / TrinPod) handle this by treating each pod as a space-time digtal twin where each pod has its own named graph in which that graph contains all matter changing via events through space-time using an rdf hypergraph (patent pending). So there is no added thing, all information is in the same rdf graph modeled on how we humans remember changing states through time. This approach has a unique webid for each pod in which that webid is the uri for the thing being modeled by the digital twin.

[pheyvaer]

@RubenVerborgh What changes do you expect here?

[RubenVerborgh]

A challenge is a technical problem applied to a concrete use case with as output a demo. I'm missing the use case and demo parts.

[pheyvaer]

@Falx Did you have the chance to look into making the necessary changes?

[Falx]

Sorry, this is not a priority right now. This was noted down as a challenge when we were still looking for useful work to do. But now that we've been fully engaged with the CSS development, this has shifted down in priority. So nothing has been done for this yet.