Add operationalPeriod to OTC station flow

[jonathanthiry]

OTC will be able to provide an operational period string in https://meta.icos-cp.eu/edit/otcentry/ which will end up in the production metadata https://meta.icos-cp.eu/edit/icosmeta/. The property will be visible on the station pages and available in SPARQL using the http://meta.icos-cp.eu/ontologies/cpmeta/hasOperationalPeriod predicate.

[Jonathan-Schenk]

Looks good to me! I do not have any comment on this.

[ggVGc]

Seems fine, just a small comment, which I think applies to several other similar cases in the code-base, so maybe something to look at as a future improvement (improving the access to StationSpecifics data).

[ggVGc]

I think this is a bit of a code-smell, where we set up a future potential issue where another StationSpecifics gets an operationalPeriod, everything builds fine, but it is not presented on this page. My first thought is that we should not have the catch-all clause, but after a quick try, it seems I did not get an exhaustiveness error if I leave out the catchall clause, possibly because it's a .scala.html file?

However, in this case, since operationalPeriod is a Maybe anyway, I think we could just make it part of the StationSpecifics trait?

[jonathanthiry]

I usually test that I get the result that I want on the page, but I see your point that it could be better to add operationalPeriod to the trait and be sure that the page always work as intended.

Removing the catch-all case would throw a runtime exception for other station types. This would throw a warning but, for some reason, we have disabled them for HTML files. I'll create a task to see if we could enable them and fix the warnings.