Kommentar Daten anders denken!

Seit Einführung der Lochkarten hat sich die Art und Weise, wie Daten definiert und gehandhabt werden, nicht wesentlich verändert. Zur Orchestrierung einer großen Geräteanzahl in einer Internetstruktur wird eine neue formale Grundlage für den Datenbegriff notwendig.

Was sind eigentlich Daten? Der Begriff scheint in aller Munde zu sein: Big Data, Datenschutz, Datenmodelle, usw. Doch: Was ist der Unterschied zwischen einer Information und einem Datum? Stimmt es, dass Datentypen für die aufwandsarme Herstellung semantischer1 Interoperabilität eine wichtige Rolle spielen?

Die letzte Frage schneidet eines der zentralen Themen im IoT-Bereich an und motiviert, sich dem Thema Daten jetzt gründlicher zu nähern.

Zwei zentrale Ideen begründeten die Informatik in der ersten Hälfte des 20ten Jahrhunderts. Zum einen fingen Elektroingenieure wie Ralph V. L. Hartley, Claude E. Shannon und andere an, in der Beschreibung kommunizierender Systeme von den physikalischen Größen wie etwa Strom, Spannung, Druck oder ähnlichem abzusehen. Gesprochen wurde nur noch über die Signalwerte insoweit, als sie unterscheidbar waren. Damit wurden neue Namen für diese unterscheidbaren Werte erforderlich, die sogenannten Zeichen. In dieser Terminologie war es nun möglich, über das Nichtstoffliche zu reden, das zwischen kommunizierenden Systemen transportiert wurde und es ließ sich sogar quantifizieren: Information!

Mit der implizierten Trennung von Transport und Verarbeitung von Information begründeten sie gleichzeitig die moderne Semantik: Transportiert wird Information und ihre Bedeutung wird durch ihre Verarbeitung erteilt.

Zum anderen machten sich Mathematiker wie Kurt Gödel, Stephen Kleene und weitere Gedanken über die Frage, welche Funktionen grundsätzlich mit finiten Mitteln konstruierbar sind. Sie schufen dazu das dreistufige Konzept der Berechenbarkeit2: Sind eine Menge von berechenbaren Elementarfunktionen gegeben, dann lassen sich alle weiteren berechenbaren Funktionen durch

  1. einfache Komposition,
  2. einfache Rekursion oder
  3. durch die sogenannte µ-Rekursion bestimmen.

In den imperativen Programmiersprachen finden sich 2. und 3. z.B. in den for- bzw. while-Schleifen.

Beide Konzepte gemeinsam begründen das Datenkonzept im Sinne einer Typisierung der Information. Alle Zeichen einer Sorte bilden ein Alphabet, betrachtet wird dieses Alphabet gemeinsam mit der Menge aller Funktionen, die auf diesem Alphabet als Daten eines Typs operieren.

Wer behauptet ein Zeichen sei ein Datum sagt damit zwei Dinge:

  1. Es gehört zu einem bestimmten Alphabet, und
  2. Alle Zeichen dieses Alphabets können von einer bestimmten Funktionsmenge verarbeitet werden, die sich aus einer bekannten Menge von Elementarfunktionen in Verbindung mit den Berechenbarkeitsregeln 1-3 ergibt.

Daten sind damit Informationen von denen grundsätzlich bekannt ist, wie sie verarbeitet werden, ohne im Detail jede mögliche Operation zu kennen.

Ein Beispiel stellt der Typ Float, wie ihn die IEEE 754-Norm mit Alphabet und Elementaroperationen festlegt. Ein anderes Beispiel sind die verschiedenen Character-Typen, wie sie vom Unicode Consortium definiert werden.

In der Welt der imperativen Programmiersprachen hilft diese Typisierung, die Verarbeitung von „unpassenden“ Informationen zu vermeiden. Wichtig ist aber, dass das Konzept der Datentypen nicht das der Programmiersprachen voraussetzt, auch wenn Typsysteme häufig mittels solcher eingeführt werden.

Ihre volle Wirkung entfalten Datentypen, wenn ihre verschiedenen Beziehungen berücksichtigt werden. Eine Beziehung zwischen zwei Datentypen ist notwendigerweise eine Beziehung zwischen ihren Alphabeten und ihrer Menge von Funktionen.

Als erstes natürlich die Komposition, beispielsweise im C-Konstrukt struct realisiert. Aber, wie jeder C-Programmierer weiß, hat eine solche Komposition nicht die wünschenswerte Eigenschaft, dass alle ihre komponierten Zeichen auch von den Funktionen der Teiltypen verarbeitet werden können. Dies wird von Subtypen im Sinne von Barbara Liskov und Jeanette Wing realisiert. Schränkt man das Alphabet eines bestehenden Typs ein (Restriktion), so ist klar, dass alle Zeichen des neuen Typs weiterhin von allen Funktionen des alten Typs verarbeitet werden können. Hinzukommende genuine-Funktionen für das reduzierte Alphabet ändern daran nichts. Dieser, durch Restriktion erzeugte Typ ist ein entsprechender (R-)Subtyp des Originals. Die Umkehrung dieser Beziehung taugt auf Grund ihres konstruktiven Charakters aber nicht zur Erweiterung eines bestehenden Typs.

Will man Alphabete eines bestehenden Types erweitern, ist sicherzustellen, dass es eine Projektion aller Zeichen des neuen Typs gibt, so dass die Funktionen des originalen Typs alle projizierten neuen Zeichen verarbeiten können. Dann lässt sich der abgeleitete Typ, diesmal als Erweiterung, wieder als ein (P-)Subtyp des Originals auffassen.

Hat man beispielsweise eine Menge von Ländern als Datentyp definiert und will diesen Typ erweitern indem man zur Zeichenmenge das Element Neuland hinzufügt, dann muss gewährleistet sein, dass es im alten Alphabet einen Wert gibt, auf den Neuland abgebildet werden kann, etwa unbekannt.

Damit ergeben sich zwei verschiedene Subtyp-Beziehung: (R-) für die Restriktion und (P-) für die Extension bestehender Typen.

Für Automatisierer interessant: Daten und Merkmale sind konzeptuell sehr ähnlich. So entsprechen auch die beiden Subtyp-Beziehungen genau den beiden Merkmalsbeziehungen von Spezialisierung (=Restriktion) und Abstraktion (=Extension). Insofern ist es nicht verwunderlich, dass sich Merkmalsysteme sehr einfach auf Datentypen abbilden lassen.

Mit der Indentifizierung von Bedeutungserteilung mit der  Informationsverarbeitung nach Claude Shannon, wird die wichtige Rolle von Datentypen für die aufwandsarme Herstellung von semantischer Interoperabilität verständlich: Beziehen sich zwei Komponenten in ihrer Interaktion auf dasselbe Typsystem, dann basiert sie auf denselben Alphabeten als auch auf denselben Mengen an Elementaroperationen. In der rekursiven Konstruktion von berechenbarer Funktionalität lässt sich damit garantieren, dass nur grundsätzlich geeignete Funktionen auf den dazu vorgesehenen Informationen operieren. In einer gegenseitig nichtdeterministischen Peer-to-Peer Beziehung bedeutet die Einigung auf ein Typsystem hingegen die Vereinbarung eines gemeinsamen Vokabulars.

Insbesondere die bisherige Unterstützung von Datentyprelationen in imperativen Programmiersprachen ist erstaunlicherweise eher unvollständig. Deutlich systematischer werden solche Ansätze in den objektorientierten Sprachen verfolgt. Allerdings sind Objekte mit ihrer festen Verbindung von Daten und explizit anzugebenden Operationen sehr viel komplexere Gebilde als Datentypen – weswegen auch ihre Typisierung komplexer ist.

Da einige Ziele der Objektorientierung auch mit Datentypen erreichbar sind, wäre es durchaus lohnenswert, sich einmal zu überlegen, wie ein datentyporientiertes Programmiermodell aussehen könnte und ob dieses nicht deutlich flexibler als ein objektorientiertes wäre. (ct)

_

Anmerkungen

1Das OSI-Modell teilt die Informationsverarbeitung in Schichten: semantisch bezeichnet die oberste relevante (Prozess-)Schicht, technisch die vergleichsweise tieferen Schichten.

2Die beiden anderen äquivalenten Konzepte der Berechenbarkeit sind die Turingmaschine und der straight lambda-Kalkül

 

Literatur

[1] Johannes Reich, Data, (2018)