📅 29. November 2018
✑ Annette Brückner (Abbe)
Es gibt viele Fragen über die ‚Analyseplattform‘, die sich die hessische Polizei bei der Firma Palantir gekauft hat und deren Betrieb sie in die Hände dieser Firma gelegt hat. Antworten sucht man allerdings vergeblich: Das hessische Polizeipräsidium für Technik als Auftraggeber hält sich extrem bedeckt. Aus dem Innenministerium hört man noch weniger. Denn die Opposition hatte noch vor der Landtagswahl einen Untersuchungsausschuss durchgesetzt: Doch der kümmert sich ohnehin nur um die sehr freihändige, zweimalige Auftragsvergabe an Palantir. Das hessische Innenministerium hat bisher trotz mehrfacher Nachfrage keine unserer Presseanfragen zu Palantir beantwortete. Und Fragen an die Firma Palantir selbst?! Deren CEO Alex Karp pflegt das Image von Palantir als dem „geheimnisvollsten Unternehmen der Welt“. Eine Telefonnummer ist auf der amerikanischen Webseite nicht zu finden. Presseanfragen können nur per Email im Silicon Valley eingereicht werden. Darauf haben wir verzichtet.
Stattdessen haben wir uns durch eine Fülle von öffentlich verfügbaren Dokumenten über Palantir und deren Produkt Gotham gearbeitet. Woraus bekanntlich ‚Hessendata‘, geworden ist, die neue Analyseplattform der hessischen Polizei. Da wäre zunächst, was die Firma selbst dazu sagt: Denn sie macht Werbung, wenn auch zurückhaltend. Und sie bedient die Medien in Amerika und Europa mit Erfolgsgeschichten über ihre Produkte. Daneben gibt es technische Kommentatoren, die sich mit Palantir beschäftigen. Und öffentliche Äußerungen von Mitarbeitern von Palantir-Kunden. Alle diese Quellen liefern Einzelinformationen, aus denen sich ein Bild ableiten ließ, wie Palantir Gotham alias Hessendata eigentlich funktioniert.
Nehmen Sie den vorliegenden Teil 5 des Palantir-Dossiers von POLICE-IT als eine Kurzbeschreibung des Systems und seiner Funktionsweise, so wie ich sie aus diesen Quellen und aufgrund meines technischen Backgrounds [a] verstehe. | Lesedauer ca 12 Minuten
Das Kardinalproblem der polizeilichen Informationsverarbeitung
Die Polizei hat im Zusammenhang mit ihrer Informationsverarbeitung zwei Kardinalprobleme.
- Polizei selbst hat – eigentlich – eine Unmenge von Informationen.
Doch diese Informationen sind verstreut gespeichert: Im Vorgangsbearbeitungssystem, dem Fallbearbeitungssystem, in Datenbanken für bestimmte Deliktsbereiche, Meldediensten, dem Asservatenverwaltungssystem der Kriminaltechnik, in den inner-polizeilichen Fernschreiben usw. Trotz großer Anstrengungen ist es bisher weder einer einzelnen Polizeibehörde, noch behördenübergreifend auch nur ansatzweise gelungen, einen zentralen Datenpool zur Verfügung zu stellen, der alle relevanten Informationen enthält. - Es fehlt am Blick auf das große Ganze:
Obwohl die Informationen ‚eigentlich‘ und ‚irgendwo‘ vorhanden sind, können sie nicht genutzt werden. Was sich die Polizei und die Innenpolitiker dringend wünschen, wurde vielfach formuliert in markigen Sprüchen: Seit über einem Jahrzehnt wiederholt die Führungsspitze im BKA ihr Mantra, man müsse „Tat-/Tat- und Tat-Täter-Zusammenhänge erkennen“ können. Oder auch „vor die Lage kommen“, was heißen soll, dass Straftaten verhindert werden sollten, bevor sie überhaupt begangen werden. Beides setzt voraus, dass die Polizei eine Art ‚Röntgenblick‘ erhält auf die ‚eigentlich‘ vorhandenen Informationen. Das wäre viel leichter, wenn wichtige Datenquellen zusammengeführt würden auf einer einheitlichen Plattform.
Palantir Gotham – Eine kurze Beschreibung des Systems und seiner Funktionsweise
Palantir Gotham alias Hessendata verspricht eine Lösung für dieses Problem:
In einer Systembeschreibung von Palantir heißt es dazu:
„Behörden haben Daten. Eine ganze Menge davon. Strukturierte Daten, wie Protokolldateien, [Excel-]Arbeitsblätter und Tabellen. Unstrukturierte Daten wie E-Mails, Dokumente, Bilder und Videos. Solche Daten werden typischerweise auf unterschiedlichen Systemen gespeichert; sie unterscheiden sich ganz erheblich voneinander, das Datenvolumen wächst über die Maßen schnell an und es wird von Tag zu Tag schwieriger damit umzugehen.
Menschen allerdings, die auf diese Daten angewiesen sind, denken nicht in Kategorien wie Datensätze oder Spalten oder Rohtext. Sie haben die Aufgabe ihrer Behörde im Blick und die aktuellen Herausforderungen mit denen diese konfrontiert ist. Die Menschen brauchen Wege, Fragen an ihre Daten zu stellen und Antworten in einer Sprache zu bekommen, die sie auch verstehen.“
Die Systemkomponenten von Palantir Gotham
Natürlich arbeitet ganz unten, im Maschinenraum von Gotham, auch ein Datenbanksystem. 
Die eigentliche Analyseplattform
Die eigentliche Analyseplattform besteht aus zwei Komponenten: 
- einer InMemory-Datenbank namens Horizon, auf der die Analytiker ihre Auswertungen durchführen und
- der Revisioning DB (RevDB) für das Speichern der Informationen aus den verschiedenen Quellsystemen
Palantir sagt darüber:
Die Revisioning Database, oder RevDB ist der Speicher zum dauerhaften Speichern in Palantir Gotham. Zu allen Informationselemente in der RevDB werden zusätzliche Informationen darüber gespeichert, wann sie erstellt oder modifiziert wurden, über den Nutzer, der sie erstellt oder verändert hat, über die Datenquelle, aus der sie ursprünglich gewonnenen wurden und etwaige Sicherheits- oder Zugriffsbeschränkungen.
Und an anderer Stelle heißt es:
Die RevDB verfolgt alle Veränderungen an einem Objekt, egal ob diese in der Datenquelle vorgenommen wurden oder von Nutzern des Palantir-Systems. Der Analytiker kann damit in seinem eigenen „Sandkasten“ Hypothesen in verschiedenen Versionen ausarbeiten und verfeinern, verschiedene Stränge für Kausalitäten oder die Beweisführung verfolgen und jederzeit auch wieder zurück gehen auf eine frühere Version der Auswertung.
Das Ergebnis ist eine Plattform über das angesammelte Wissen und die Hypothesen der Nutzer, wodurch deren Analysen in Informationen verwandelt werden, die von der Organisation zu deren Vorteil eigesetzt werden können [wörtlich: „turning their analyses into data that can be further leveraged by the enterprise“].
Tools für Suche und Auswertung
Zwischen den Datenspeichern und den Anwendungen, mit denen die Nutzer arbeiten, wirken im Hintergrund und ohne dass der Nutzer davon viel mitbekommt, Systemdienste mit so klangvollen Namen wie ‚Raptor‘ (zu deutsch: Raubvogel), ‚Phoenix‘ (noch ein Vogel, diesmal aus der Asche) oder einfach ‚Search‘. Aufhorchen lässt die knappe Beschreibung [a] von ‚Raptor‘, einem Dienst der „on-the-fly“ federated searches auf externen Datenquellen ausführt. Das legt folgende Arbeitsweise nahe: Ein Auswerter interessiert sich für eine Person X. ‚Raptor‘ muss dann vermutlich aktiviert werden und würde in diesem Moment alle (vermutlich definierten) anderen, externen Datenquellen nach dieser Person X durchsuchen. Treffer in diesen Datenbanken werden dann – sagt Palantir – in die Revisioning DB übernommen und dort gespeichert. Sehr spannend finde ich in diesem Zusammenhang die Frage, welche „externen Datenquellen“ in Hessendata für den Dienst ‚Raptor‘ zur Verfügung stehen. Und ob dazu auch Abfragen in sozialen Medien, wie Facebook, Twitter & Co gehören!
Die Apps = Anwendungen
Die Anwendungen stellen die „Schnittstelle“ dar, mit denen die Nutzer mit der Analyseplattform kommunizieren, dort Eingaben machen oder Auswertungen durchführen.
Ich gehe ganz bewusst nicht näher auf dieses Anwendungen ein. Erstens können Sie selbst leicht entsprechende Bildschirmfotos im Internet finden. Zweitens ist an diesen Anwendungen nichts so richtig neu. Schon lange vorher gab es und gibt es immer noch Analyst’s Notebook und verwandte Produkte von IBM. POLYGON kann auch schon sehr lange ‚graph‘, also die Darstellung von miteinander vernetzten Objekten „on-the-fly“. Und der „Object Explorer“ liefert offensichtlich eine Art Dossier über eine Person mit allen relevanten Informationen und Dokumenten, die ein Auswerter in diesem Dossier mal zusammengeführt hat. So etwas nannte man schon zu DDR-Zeiten ein ‚Personagramm‘ und auch das ist in aktuell verwendeten Fallbearbeitungssystemen längst Standard …
Was die Apps von Gotham für die Nutzer attraktiv machen dürfte, ist die Mischung aus Komfort, Einfachheit in der Bedienung, Schick und vermutlich auch ein Anteil von „Spaß und Spiel“. Denn solche modernen ‚Apps‘ machen dem Nutzer natürlich mehr Spaß als die altbackene, dröge Benutzeroberfläche der bisher genutzten polizeilichen Informationssysteme, die vor fünfzehn bis zwanzig Jahren entwickelt wurden. Mit den Apps von Gotham/Hessendata kann man auf einer grafischen Oberfläche mit Daten „herumspielen“, mal eine Idee ausprobieren und sich – „zeig mal, wohin diese Beziehung im grafischen Netzwerk führt“ – zeigen lassen, wohin die führt. Für einen Auswerter ist ein solches Werkzeug eine willkommene – und sinnvolle! – Unterstützung zur Aktivierung der eigenen Kreativität und Unterstützung der Hypothesenbildung. Gefährlich wird es, wenn solche „Gedankengänge“ von der Analyseplattform Horizon zurückgespeichert werden in den permanenten Speicher der Revisioning DB. Ich sehe darin die Gefahr, dass solche Gedankenspiele, also Hypothesen des Analytikers von echten, bewiesenen Fakten nicht mehr deutlich genug unterschieden werden können. Und polizeiliche bzw. strafrechtliche Entscheidungen zunehmend mehr auf Annahmen als auf Fakten basieren.
Für Hessendata muss die Zukunft zeigen, ob eine für den Nutzer und Betrachter attraktive Benutzeroberfläche und die Präsentation von „Erkenntnissen“ in vielen schönen Bildern wirklich mehr bringt: Letztlich geht es für eine verantwortungsvoll agierende Polizei um belastbare Erkenntnisse, die die Basis bilden für anschließende Entscheidungen. Ist Palantir wirklich in der Lage, eine alte Faustregel auszuhebeln: Die besagt, dass Erfolg zu 95% auf Transpiration beruht und zu 5% auf Inspiration?!
Es wäre zu hoffen, dass diese Frage OBJEKTIV untersucht und beantwortet wird. Und nicht allein von frühen Adepten der Firma aus dem hessischen Innenministerium, die einen Erfolg brauchen nach ihrem sturen, letztlich aber gescheiterten Festhalten an der hessisch-hamburgischen Eigenentwicklung CRIME. Und auch nicht von Anwendern in einem Polizeipräsidium, denen das Innenministerium die Chance gegeben hat, mehr Primus zu sein, als das LKA des Landes.
Die flexible Speicherstruktur
Weitaus mehr als die schicken Apps von Palantir steckt die Leistungsfähigkeit dieses Systems tief unter der Motorhaube: Und zwar insbesondere in seinem Daten- und Informationsmodell:
Palantir sagt selbst:
In Gotham werden Informationen als Graphen behandelt, an deren jeweils einem Ende ein Informationsobjekt sitzt, das mit dem anderen durch eine (benannte) Beziehung verbunden ist. Diese Informationsobjekte sind Repräsentanten für Objekte aus der realen Welt, wie Menschen, Unternehmen, Sachen, Orte der Ereignisse, usw. Sie werden mit Attributen näher beschrieben oder identifiziert (Namen, KFZ-Kennzeichen, Telefonnummer) und können mit Beziehungen miteinander verknüpft werden.
Die verwendete Speicherstruktur in Palantir Gotham ist im Kern nicht neu. Sie ähnelt im Prinzip der so genannten EAV/CR-Struktur bzw. dem generischen Datenmodell, wie es in der Polygon-Patentschrift [1] beschrieben und in POLYGON realisiert und als Variante davon im Fallbearbeitungssystem CRIME (eingesetzt u.a. in Hessen) und in INPOL-Fall (eingesetzt beim BKA als Plattform für kriminalpolizeiliche Meldedienste) verwendet wird.
Für den Beobachter bleibt ein ironisches Schmunzeln nicht aus: Denn Hessen braucht dringend einen Nachfolger für CRIME und beschafft sich mit Palantir Gotham alias Hessendata nun ein neues System mit einer sehr ähnlichen Speicherstruktur wie die von CRIME. Ob sich die Entscheider im hessischen Innenministerium und Landespolizeipräsidium darüber klar sind?! Und ob sie haben prüfen lassen, welche Fehler, die zum Aus von CRIME führten (und die nichts mit dessen Datenmodell zu tun hatten!), beim Einsatz von Palantir tunlichst zu vermeiden sind?!
Vier wesentliche Strukturelemente
- Das gemeinsame Merkmal der oben genannten Speicherstrukturen ist ihre Objekt-Orientiertheit. Jede Einzel-Information bezieht sich auf ein Informationsobjekt, wie z.B. Personen, Orte, Sachen, Ereignisse usw. Für jedes Objekt, das im Ausgangs-Datenmaterial erkannt wird, wird in der Datenbank ein Informationsobjekt gebildet.
- Alle Details, die ein Objekt näher beschreiben oder auch identifizieren, werden diesem Informationsobjekt in der Datenbank als Attribute / Merkmale / Features (jeder nennt es anders ..) zugeordnet.
- Eine Beziehung verknüpft jeweils ein Informationsobjekt mit einem zweiten und macht eine Aussage über die Art der Beziehung (Geschäftsführer, Mieter, Fahrzeughalter, usw.).
- Und dann gibt es in der Datenbank noch (mindestens) einen Speicherbereich zum Speichern von Dokumenten, Bildern, Tonmitschnitten und Videos.
Die Speicherbereiche
Für jedes dieser vier Strukturelemente gibt es einen eigenen Speicherbereich, nämlich 
CIVES Redaktionsbüro GmbH / Abbe
- einen Speicherbereich für sämtliche Informationsobjekte, egal ob es sich um Personen, Orte, Sachen, Ereignisse oder sonst was handelt: Darin wird mindestens eine Bezeichnung für das Objekt gespeichert, sowie der Objekttyp, der besagt, ob es sich um ein Person, einen Ort, eine Sache oder ein Ereignis usw. handelt. Anders als in konventionell modellierten Datenbanken, werden in diesem Speicherbereich für die Informationsobjekte jedoch keine Attribute gespeichert!
- einen Speicherbereich für sämtliche Attribute zu allen Objekten: Darin wird für jedes Attribut ein Attributbegriff gespeichert, sowie die dazugehörende Attributbedeutung.
Die Zuordnung von Attributen zu dem Informationsobjekt, das sie näher beschreiben oder identifizieren, ist in den o.g. Speicherstrukturen auf unterschiedliche Weise gelöst: Der Verweis auf das zugehörige Objekt kann im gleichen Speicherbereich wie das Attributpärchen gespeichert sein. Oder es gibt einen eigenen Speicherbereich, der einen Verweis auf das Attributpärchen (Haarfarbe:braun) und einen weiteren Verweis auf das zugehörige Objekt enthält. - einen Speicherbereich für sämtliche Beziehungen. Darin wird für jede Beziehung ein Verweis auf das erste und auf das zweite Objekt gespeichert und zusätzlich eine Aussage über die Beziehung.
- einen oder mehrere Speicherbereiche für die Dokumente, Bilder etc.: Darin wird der elektronische Inhalt des Dokuments, Bilds, der Audio-oder Videosequenz gespeichert.
Und zusätzlich gibt es in jedem dieser Speicherbereiche für jedes einzelne Element einen eigenen Schlüssel (Key), der für die Referenzierung und Verwaltung innerhalb des Systems benötigt wird.
Logisches Informationsmodell
Allerdings wirft diese Speicherstruktur ein Problem auf: Denn es gibt jetzt ja nur noch EINEN Speicherbereich, in dem SÄMTLICHE Informationsobjekte zumindest mit ihrem Namen gespeichert werden. Damit man aber Personen von Orten und Sachen von Ereignissen usw. unterscheiden kann, muss zusätzlich ein Objekttyp angegeben werden. ObjektTYPEN dienen also dazu, gleichartige Informationsobjekte, wie Personen, Orte, Sachen und Ereignisse etc. zu Gruppen zusammen zu fassen und innerhalb der Gruppe miteinander vergleichbar zu machen.
Ganz ähnlich sieht es bei den Attributen aus: Auch dort wird ein AttributTYP benötigt, denn der AttributBEGRIFF alleine würde ja keine Aussagekraft haben: Stellen Sie sich zum Beispiel ein Datum vor, wie „06.11.2012“. Alleinstehend kann man überhaupt nicht sagen, was dieses Datum für eine Bedeutung hat. Erst durch die zugefügte Attributbedeutung weiß man, dass es sich um ein Geburtsdatum handelt oder um das Datum, zu dem ein Versicherungsvertrag abgeschlossen worden ist oder ein Unfall geschehen ist.
(C) CIVES Redaktionsbüro GmbH / Abbe
Speichermodelle, wie EAV/CR, POLYGON und ähnliche Variante, wie CRIME bzw. INPOL-Fall speichern die Typ-Informationen beim jeweiligen Objekt oder Attributbegriff usw. explizit mit. Demzufolge braucht es in diesem Datenmodell eine Möglichkeit, um die im System zulässigen und bekannten Objekttypen, Attributbedeutungen usw. EINMAL zu definieren und zu hinterlegen. Allgemein nennt man einen solchen Vorrat der Typ-Informationen für Informationsobjekte, Attribute, aber auch für Beziehungen und Dokumente ein „logisches Informationsmodell„.
Das logische Informationsmodell von Palantir, die „dynamische Ontologie“
Palantir bezeichnet sein Datenmodell und das logische Informationsmodell darin als „dynamische Ontologie“. {Der Begriff Ontologie wird mitunter als Synonym für „logisches Informationsmodell“ verwendet.} Und dynamisch ist dieses Informationsmodell insofern, als es frei definiert und auch erweitert werden kann. Ohne dass deswegen die eigentliche Speicherstruktur, also das physische Datenmodell angelangt werden muss.
Beim Schreiber der Palantir-Datenblätter geht es ein wenig hin und her mit den Begriffen: Denn das „objektbasierte Datenmodell“ ist die eine Sache – wir hatten sie oben korrekt als das physische Speichermodell beschrieben. Und das logische Informationsmodell ist die zweite Sache. Sie heißt bei Palantir die dynamische Ontologie [A].
Aus beidem zusammen wird ein funktionierendes Ganzes:
Das flexible, vereinheitlichte Datenmodell in Palantir Gotham vereinfacht den Prozess der Datenintegration ganz ungemein. Und die dynamische Ontologie in Palantir Gotham erlaubt es, Informationen aus ganz unterschiedlichen Quellsystemen und Speicherformaten in Informationsobjekte und zugehörige Attribute zu verwandeln, die Objekte aus der realen Welt und die Beziehungen zwischen diesen Objekten repräsentieren.
Die „dynamische Ontologie“ ist also das logische Informationsmodell, also der Vorrat an Objekttypen, Attributbedeutungen, Beziehungstypen usw., die in einer funktionsfähigen Gotham Analyseplattform zum Einsatz kommen.
Die Datenquellen von Hessendata
Die SZ berichtete [2], dass Daten aus diesen Datenbanken und Quellsystemen in Gotham alias Hessendata integriert werden können:
- drei „Polizeidatenbanken für Kriminalfälle und Fahndungen“
Plausibel wäre, wenn es sich dabei handelt um- die INPOL-Personenfahndung (INPOL/POLAS)
- die INPOL-Sachfahndung ((INPOL/POLAS)
- die Datenbank des Fallbearbeitungssystems CRIME, sowie
- Verbindungsdaten aus der Telefonüberwachung (tabellarisch)
- Daten aus ausgelesenen Handys
- BKA-Fernschreiben (EPOST810)
Integration bzw. Mapping der Quelldaten
In enger Abstimmung mit dem Auftraggeber, heißt es weiter im Palantir-Datenblatt, integrieren und mappen unsere [Palantir-] Techniker alle relevanten Daten aus den Quellsystemen und zwar unabhängig von deren Art oder Menge – und überführen sie in ein einziges, logisches Datenmodell.
Es ist nachvollziehbar, dass diese Definitionen für die Integration bzw. das ‚Mapping‘, also die Zuweisung von Informationen auf Quellsystemen auf das Palantir-Zielsystem von Technikern der Firma vorgenommen werden.
Wenn dies, nach einem öffentlich nicht bekannten Zeit- und Kostenaufwand geschehen ist, lesen wir in einer Palantir-Produktbeschreibung weiter: Sobald das Datenmodell und die Integration und Zuweisungsinformationen erst einmal erstellt worden sind, „fließen die Daten kontinuierlich aus ihren jeweiligen Quellsystemen in die Palantir-Gotham-Plattform“.
Das muss für so manchen Polizeipraktiker wie eine himmlische Verheißung klingen. Einmaliger Aufwand, der sicher Zeit und Geld kostet. Aber wenn das erst einmal investiert worden ist, hat man endlich eine Plattform, auf der relevante Informationen aus vielen verschiedenen Datenquellen zusammengeführt und gemeinsam genutzt werden können. Lassen wir diesen scheinbaren Himmel auf Erden zunächst einmal so stehen. Denn wie zu allen himmlischen Darstellungen gibt es auch hier berechtigte Fragen, die aus Erfahrungen mit der irdischen Welt gespeist werden: Doch dazu mehr im Teil 6 Palantir-Dossiers von POLICE-IT: Dammbruch in der polizeilichen IT.
Das Palantir-Dossier – die bisher erschienen Beiträge
https://police-it.net/das-palantir-dossier
Disclaimer
Annette Brückner, die Autorin dieses Artikels, war zwischen 1993 und 2013 Projektleiterin für das polizeiliche Informationssystem POLYGON und in diesem Zusammenhang Designerin von Werkzeugen zur Strukturermittlung, Analyse und Auswertung für den polizeilichen Staatsschutz, sowie für OK-Ermittler und -Analytiker.
Sie hat 1995 die Patentschrift [1] für das oben erwähnte generische Speichermodell von POLYGON geschrieben. Dieses Patent wurde in Deutschland, Österreich, der Schweiz, den Niederlanden und den Vereinigten Staaten erteilt und ist hier einsehbar.
Fußnote
[a] „The Palantir Raptor service provides in-place federated searching of external data sources. Raptor utilizes an On-The-Fly (OTF) approach to data integration. When a federated query identifies a Raptor result, that record is transferred to the Revisioning Database on-the-fly.“Quellen
[1] Information system and process for storing data therein, US-Patentschrift US6208992B1, erteilt am 27.03.2001, Annette Brückner
https://patents.google.com/patent/US6208992B1/en?oq=US6208992
[2] Palantir in Deutschland: WO die Polizei alles sieht, 18.10.2018, Süddeutsche Zeitung Online
https://www.sueddeutsche.de/digital/palantir-in-deutschland-wo-die-polizei-alles-sieht-1.4173809
Verwandte Beiträge
[A] Wie kommt das Informationsmodell ins Datenmodell?, POLICE-IT
https://police-it.net/itfdf6_infmodell_datenmodell
[B] Dossier: Informationstechnik für die (polizeiliche) Fachlichkeit
https://police-it.net/informationstechnik-fuer-die-polizeiliche-fachlichkeit
Copyright und Nutzungsrechte
(C) 2018 CIVES Redaktionsbüro GmbH
Sämtliche Urheber- und Nutzungsrechte an diesem Artikel liegen bei der CIVES Redaktionsbüro GmbH bzw. bei dem bzw. den namentlich benannten Autor(en). Links von anderen Seiten auf diesen Artikel, sowie die Übernahme des Titels und eines kurzen Textanreißers auf andere Seiten sind zulässig, unter der Voraussetzung der korrekten Angabe der Quelle und des/der Namen des bzw. der Autoren. Eine vollständige Übernahme dieses Artikels auf andere Seiten bzw. in andere Publikationen, sowie jegliche Bearbeitung und Veröffentlichung des so bearbeiteten Textes ohne unsere vorherige schriftliche Zustimmung ist dagegen ausdrücklich untersagt.