ConvConf

Problemstellung

Ursprünglich dachte man, dass jeder System-Hersteller, der im öffentlichen CH-Markt tätig ist, den Daten-Transfer mit INTERLIS anbietet.

In der heutigen Realität ist dies aber nicht der Fall. Es sind vielmehr die System-Betreiber, die sich um INTERLIS kümmern.

• Oft wird die nötige Konversion für das spezifische Modell gebaut
• Folge: Hoher Aufwand, erhebliches Fehlerrisiko

Da sich auf Grund der föderalen Unterschiede die Datenmodelle und ihre Umsetzung in Datenbanken in den verschiedenen Kantonen erheblich unterscheiden, steigt der durchaus erhebliche Entwicklungsaufwand selbst für Datenlieferung gemäss minimalem Datenmodell des Bundes im Wesentlichen mit der Anzahl Modelle multipliziert mit der Anzahl Kantone.
Noch schwieriger wird die Situation beim Datenbezug für verschiedenste Nutzungen durch Amtsstellen und Private (insbesondere Ing-Büros), da die Nutzer die Daten oft nicht gemäss dem Originalmodell sondern in einer vereinfachten Form und in Formaten, die durch ihr System vorgegeben sind, beziehen möchten.

Zielsetzung

Gesucht ist eine Lösung, dank welcher der Aufwand für den Transfer von Daten eines bestimmten konzeptionellen Datenmodells zwischen verschiedenen Systemen minimal ist und nur für die einzelnen Systeme nicht aber für deren Sender-/Empfänger-Kombination geleistet werden muss.

Lösungsidee

Alle, die an Daten eines bestimmten Themas interessiert sind, orientieren sich am gemeinsamen konzeptionellen Datenmodell (KM) – vorzugsweise in INTERLIS2 formuliert.

Mittels der ConvConf-Sprache wird für ein bestimmtes System das individuelle logische Modell (LM) beschrieben:

• Beschreibung der Struktur der System-Daten
  Arten von Datensätzen mit Attributen (Wert-Attribute und Verweise auf andere Datensätze) und eingeschachtelten Datensätzen.
• Beschreibung des Zusammenhangs mit dem KM
  Mittels Views, welche auf den Klassen des KM aufsetzen, wird beschrieben, wie sich die Datensätze ergeben.

Für einen Datentransfer von Sender-Daten gemäss Sender-LM ins Empfänger-System, das Daten gemäss Empfänger-LM erwartet, müssen sich Sender und Empfänger nicht kennen. Der Brückenschlag erfolgt mittels ConvConf.

Brückenschlag mittels ConvConf

Der Konversions-Konfigurator ConvConf benötigt als Input:

• Das für die Daten massgebende konzeptionelle Datenmodell KM
• Die logischen Datenmodelle (LM) der systemspezifischen Datenformate.

Der Konversions-Konfigurator ConvConf leitet daraus die für die Konversion nötige Konfiguration ab. Es werden Views beschrieben, welche auf den Sender-Daten aufbauen und Datensätze gemäss LM des Empfängers produzieren.

Zusätzliche Informationen:

• Weitere Informationen zu ConvConf
• Einstieg mit Beispielen, welche zeigen, wie einfach LM's formuliert werden können.
• Datei mit dem KM und verschiedenen aktuellen LM's.

Aktueller Stand und Ausblick

ConvConf liegt aktuell als funktionierender Prototyp vor, mit dem auch die vorliegenden Beispiele prozessiert wurden.
Man kann also sagen:
Der POC (Proof of concept) ist erbracht.

Auf Basis von ConvConf eröffnet sich die Perspektive, dass Daten-Interoperabilität durch einen Dienst angeboten wird und damit kein Problem mehr darstellt.

Das wäre doch eine tolle Sache.

Gesucht ist nun ein Vorgehen, damit ein solcher Dienst entsteht und nachhaltig betrieben wird.