Not possible to describe interrupted timeseries

[christian-rli]

As was noted in a table in review OpenEnergyPlatform/data-preprocessing#75 it is not possible to make a detailed description of gaps in timeseries. In the original issue, a table with data from 2030 and 2050 and no data in between needed a start and end value for the timeseries. Techincally, it would have been possible to create two tables and be done with it, which also seems more correct. However this would ignore the larger issue. All kinds of gaps may occur due to problems in the creation. It's not a feasible approach to break apart tables after every little gap.

When a long timeseries misses, say, a month, there are several options that I see:

1. Ignore gaps in the metadata and set the first date as start and the last date as end.
2. Create a new table after every gap
3. Find a way to mention the gaps in the metadata in a newer version
4. Find a compromise solution where e.g. there are tables for every year and gaps within can be ignored but for timeseries with a year or longer gap, require yearly tables

This should be discussed for the next standard.

(In the original issue, we opted for solution 1)

[christian-rli]

Also see the issue in the ontology related to timeseries: OpenEnergyPlatform/ontology#267

[chrwm]

+1 the issue is still relevant. It's not possible to annotate data that stem from separate years. e.g. 2020, 2030, 2040

[chrwm]

What about changing the value of the timeseries key to a list of dicts with its current subkeys.
It could be implemented like this:

"temporal": {
        "referenceDate": "2016-01-01",
        "timeseries": [{
            "start": "2016-01-01T00:00+01",
            "end": "2016-12-31T23:00+01",
            "resolution": "1 h",
            "alignment": "left",
            "aggregationType": "sum"
        }, 
        {
            "start": "2018-01-01T00:00+01",
            "end": "2019-12-31T23:00+01",
            "resolution": "1 h",
            "alignment": "left",
            "aggregationType": "sum"
        }]

This way multiple time periods (values) can be entered for the timeseries key and the flexibility for their specification remains.
@christian-rli could this implementation work?

[chrwm]

The change has been implemented in v1.5.0 as described above.