# BAFU Planung 2020

## Ausbau Frontend Table-Mapping (Prio 1)

### Integration zusätzlicher Metadaten

Die Benutzerschnittstelle für das Konvertieren von CSV basierten Daten nach RDF steht Ende 2019 als Version 1.0 zur Verfügung. Mit dieser wird man

* CSV Dateien hochladen
* Mappings der Spalten nach RDF definieren
* Entsprechende Vorschau der gemappten Daten erhalten
* Eine entsprechend konfigurierte Pipeline ausführen können, welche die Daten nach RDF transformiert und bereitstellt respektive in einen Triplestore schreibt

Um die Daten im Werkzeug von Interactive Things korrekt visualisieren zu können, fehlen zusätzliche Metadaten wie:

- Name des Cubes
- Beschreibung
- Definition und Beschreibung sämtlicher Spalten (Spaltenname alleine reicht nicht aus)
- Zusätzliche Metadaten zu den Spalten wie Einheit, Scale of Measure etc.

Diese Metadaten sollten zudem im Idealfall mehrsprachig vorliegen.

Diese Daten entweder von bestehenden Quellen abgeholt werden können oder über zusätzliche Dialoge im CSV Mapping Werkzeug gepflegt werden können. Die Benutzer sollten dabei unterstützt werden, möglichst vollständige und gut gepflegte Metadaten bereit zu stellen.

Lieberobjekte:

- Dialoge zum Erfassen fehlender Metadaten
- Oder abholen derselben an anderer Stelle (Opendata.swiss?)
- Unterstützung beim Übersetzen sämtlicher Texte in den Masken
- Einführen von Regeln für die Spalten (Max/Min Werte, Datentypen etc), für automatisches interpretieren & Validieren der Daten

### Pflege von Codelisten

Aktuell gibt es keine zentrale Stelle, wo Codelisten projektübergreifend gepflegt werden können. Dadurch wird durch jede Transformation neue Codelisten erstellt, die sich mit zunehmenden Daten früher oder später überschneiden werden. Das macht speziell dann Sinn, wenn diese in mehreren Sprachen vorliegen sollen.

Codelisten werden in RDF typischerweise über die [SKOS](https://www.w3.org/TR/skos-primer/) gepflegt, welches zu den ältesten Anwendungsfällen im RDF Umfeld gehört. Folglich soll ein Werkzeug erstellt werden, welches das Pflegen und Verlinken von Codelisten und deren Konzepte Datensetübergreifend unterstützt.

Diese Problemstellung ist nicht zu unterschätzen, da die Datenquellen wohl auf absehbare Zeit keine vereinheitlichte Codeliste verwenden werden und somit sicher gestellt werden muss, dass diese weiterhin die bestehenden Namen verwenden können.

Lieferobjekte:

- Werkzeug um Codelisten separat von den Daten pflegen zu können (ähnlich wie in Indikatoren DB, aber grösserer Scope & Datensatz-übergreifend)

### Integration von Georeferenzierten Daten

Viele der Daten verwenden in irgend einer Form Geobezogene Daten. Beispiel: Bei den Cubes für die Walddaten. Diese werden aktuell nur als Codeliste gepflegt, die keinen Bezug zu den Geodaten von Swisstopo oder dem historisierten Gemeindeverzeichnis hat.

Es sollte folglich möglich sein, solche Codelisten korrekt mit bestehenden Quellen von Swisstopo oder BFS verlinken zu können. Damit kann auf die entsprechenden Metadaten (Historie, Shapes, aktuelle Gemeindenamen etc.) zugegriffen werden, ohne das die Daten im BAFU selber dupliziert und folglich auch gepflegt werden müssen.

In einem weiteren Schritt muss die API für den Frontend entsprechend angepasst werden, dass diese erweiterten Codelisten mit externen Datenquellen verwendet werden können.

Lieferobjekte:

- Integration von Georeferenzierten Daten (z.b. von Swisstopo), Einbindung in den Frontend
- Anpassen der API für IXT

## Datenmapping 2.0 (Prio 2)

Die Arbeiten für das Konvertieren von CSV Daten liefern die technische Basis für eine mögliche Indikatoren DB Version 5.0. Die Datenstrukturen und ein Teil der dafür notwendigen Dialoge zum Erfassen von Metadaten würde bestehen.

Diese Basis würde ausgebaut bis zum Punkt, wo sie als Ersatz für die bestehende Indikatoren DB 4.x in Frage kommt. Das beinhaltet unter anderem das Editieren von Daten in einer Webschnittstelle und das exportieren & importieren der Daten via Excel/CSV Schnittstelle. Dafür würde zusätzlich eine Versionierung der Daten in das Modell eingebaut.

Lieferobjekte:

- Daten können in Excel/CSV importiert & exportiert werden
- Daten können direkt im Webinterface gepflegt werden
- Versionierung der Daten

### Webschnittstelle Pipeline Poweruser

Die CSV Webschnittstelle beschränkt sich auf Daten, welche als Cubes bereitgestellt werden können. Dies sind typischerweise Zeitreihen jewelcher Art. Andere Daten können ohne weiteres konvertiert werden, allerdings steht dafür aktuell nur ein Backend mit dem Namen [barnard59](https://github.com/zazuko/barnard59/wiki/Primer) zur Verfügung mit viel Funktionalität.

Es gibt ein Proof-of-concept einer Webapplikation, die es Poweruser ermöglicht, eigene barnard59 Pipelines zu bauen. Diese könnte entsprechend den Anforderungen solcher Nutzer ausgebaut werden.

Lieferobjekte:

- Bessere Webschnittstelle zum Automatisieren von Transformationen
- Erstellen von Schedules ohne GitLab Interaktion (z.b. Daten einmal wöchentlich abholen, konvertieren & publizieren)

### Zusätzliche Operatoren für die Pipeline

Das für das Bundesarchiv entwickelte Pipelining-System barnard59 bietet die [Basisfunktionalität](https://github.com/zazuko/barnard59/wiki/Primer#core), welche für die aktuell umgesetzten Projekte zwingend ist. Zusätzliche Operatoren können je nach Anforderungen als Module entwickelt und bereit gestellt werden.

Lieferobjekte:

* Zusätzliche Operatoren, auf Basis der Anforderungen in neuen Projekten

### Stundenpool

Für Fälle, die aktuell noch nicht bekannt sind. Support bei der Integration neuer Anwendungsfälle nach Aufwand.

# FOEN planning 2020

## Extension Frontend Table-Mapping (Prio 1)

### Integration of additional metadata

The user interface for converting CSV-based data to RDF will be available as version 1.0 at the end of 2019. With this version you will be able to

* Upload CSV files
* Define mappings of the columns according to RDF
* Corresponding preview of the mapped data
* Execute a pipeline that transforms the data to RDF and makes it available or writes it to a triplestore

In order to be able to correctly visualize the data in the Interactive Things tool, additional metadata such as:

- Name of the Cube
- Description
- Definition and description of all columns (column name alone is not enough)
- Additional metadata for the columns such as unit, scale of measure etc.

This metadata should ideally be available in several languages.

This data can either be retrieved from existing sources or maintained via additional dialogs in the CSV mapping tool. Users should be supported in providing metadata that is as complete and well maintained as possible.

Dear objects:

- Dialogs for entering missing metadata
- Or pick it up elsewhere (Opendata.swiss?)
- Support in translating all texts in the masks
- Introduction of rules for the columns (max/min values, data types etc), for automatic interpretation & validation of the data

### Maintenance of code lists

Currently, there is no central location where code lists can be maintained across projects. This means that new code lists are created by each transformation, which will sooner or later overlap with increasing data. This makes particular sense if these are to be available in several languages.

Codelists in RDF are typically maintained via [SKOS](https://www.w3.org/TR/skos-primer/), which is one of the oldest use cases in the RDF environment. Consequently, a tool is to be created that supports the maintenance and linking of code lists and their concepts across data sets.

This problem should not be underestimated, since the data sources will probably not use a unified code list in the foreseeable future and therefore it must be ensured that they can continue to use the existing names.

delivery objects:

- Tool to maintain code lists separately from the data (similar to Indicator DB, but larger scope & dataset-spanning)

### Integration of Georeferenced Data

Much of the data uses geospatial data in some form or another. Example: In the cubes for the forest data. These are currently only maintained as a code list, which has no reference to the geodata of Swisstopo or the historicised municipal directory.

It should therefore be possible to link such code lists correctly to existing Swisstopo or BFS sources. In this way, the corresponding metadata (history, shapes, current names of municipalities, etc.) can be accessed without having to duplicate and therefore maintain the data in the FOEN itself.

In a further step, the API for the frontend must be adapted so that these extended code lists can be used with external data sources.

Delivery objects:

- Integration of georeferenced data (e.g. from Swisstopo), integration in the frontend
- Customizing the API for IXT

## Data mapping 2.0 (Prio 2)

The work for converting CSV data provides the technical basis for a possible indicator DB version 5.0. The data structures and some of the necessary dialogs for capturing metadata would exist.

This basis would be extended to the point where it could be considered as a replacement for the existing indicators DB 4.x. This would include editing data in a web interface and export & import of data via Excel/CSV interface. For this purpose, a versioning of the data would also be built into the model.

Delivery objects:

- Data can be imported & exported in Excel/CSV
- Data can be maintained directly in the web interface
- Versioning of the data

### Web Interface Pipeline Poweruser

The CSV web interface is limited to data that can be provided as cubes. These are typically time series of a particular type. Other data can be converted without any problems, but currently there is only a backend called [barnard59](https://github.com/zazuko/barnard59/wiki/Primer) with a lot of functionality available.

There is a proof-of-concept of a web application that allows power users to build their own barnard59 pipelines. This could be extended according to the requirements of such users.

delivery objects:

- Better web interface for automating transformations
- Create schedules without GitLab interaction (e.g. retrieve, convert & publish data once a week)

### Additional operators for the pipeline

The pipelining system barnard59 developed for the Federal Archive offers the [basic functionality](https://github.com/zazuko/barnard59/wiki/Primer#core), which is mandatory for the currently implemented projects. Additional operators can be developed and provided as modules according to requirements.

Delivery objects:

* Additional operators, based on the requirements in new projects

### Hour pool

For cases which are not yet known at present. Support during integration