Von Datenfriedhöfen zu Wissenslandschaften

Europa besitzt enorme öffentliche Datenbestände, doch deren ökonomischer und gesellschaftlicher Mehrwert bleibt bislang hinter den Erwartungen zurück. Ursachen dafür sind fragmentierte Datenportale, inkompatible Schnittstellen sowie zunehmende Abhängigkeiten von außereuropäischen Plattformen – allesamt Faktoren, die echte Innovation hemmen.

‍

Parallel dazu entstehen in der Industrie neue Datenräume (Data Spaces), beispielsweise im Rahmen von Gaia-X, Catena-X oder dem International Data Spaces (IDS)-Referenzmodell. Im Unterschied zu klassischen Open-Data-Portalen ermöglichen diese Datenräume den sicheren, strukturierten und branchenübergreifenden Austausch sensibler Informationen – auf Basis standardisierter Verträge, Identitäts- und Zugriffsmechanismen. Jeder Teilnehmer behält dabei die Kontrolle über seine Daten, während ein vertrauenswürdiges Ökosystem für kollaborative Wertschöpfung geschaffen wird.

‍

Als Folge existieren heute zwei umfangreiche, aber weitgehend voneinander getrennte Datenwelten:

‍

1. frei verfügbare Open-Data-Bestände aus dem öffentlichen Sektor
2. domänenspezifische Industrie-Data-Spaces mit hoher Detailtiefe und klaren semantischen Standards

‍

Beide Bereiche bergen großes Wissen – doch solange es keine verbindende, einfach nutzbare Brücke gibt, bleibt dieses Potenzial ungenutzt. Im Folgenden erfahren Sie, wie Künstliche Intelligenz (KI) und das Model Context Protocol (MCP) gemeinsam den Weg von Open Data zu Open Knowledge ebnen – und wie Sie als Entscheider eine nahtlose Vernetzung öffentlicher und industrieller Datenbestände vorantreiben können, ohne die digitale Souveränität Ihres Unternehmens zu gefährden.

‍

Open Data & Data Spaces: Daten zugänglich, aber ohne Nutzen

‍

Das Paradox der europäischen Open-Data-Strategie

‍

Open Data steht für das Prinzip, Verwaltungs- und Forschungsdaten offen, maschinenlesbar sowie ohne rechtliche oder technische Zugangsbarrieren bereitzustellen. Dieser Gedanke ist keineswegs neu: Schon 2003 verpflichtete die sogenannte PSI-Richtlinie (Public Sector Information) die EU-Staaten, öffentlich finanzierte Daten bestmöglich zugänglich zu machen. 2019 wurde mit der Open Data Directive der Rahmen nochmals gestärkt – mit dem Ziel, Innovation, Transparenz und wirtschaftliches Wachstum zu beflügeln. Infolgedessen stellen Behörden unterschiedlichste Datensätze bereit, von Geodaten und Wetterinformationen bis hin zu Haushaltszahlen und Verkehrsdaten – mit dem Anspruch, daraus neue Services und Erkenntnisse zu ermöglichen.

‍

Die Realität sieht jedoch anders aus: Zwischen Anspruch und tatsächlichem Mehrwert klafft eine deutliche Lücke. Offene Daten sind reichlich vorhanden, aber ihre gesellschaftliche Wirkung bleibt marginal.

‍

Trotz erheblicher Investitionen wird nur ein Bruchteil dieses Potenzials ausgeschöpft. In Deutschland existieren beispielsweise über 500 Open-Data-Portale – doch jedes arbeitet mit eigenen Metadatenstrukturen, Formaten und Schnittstellen. Für Entwicklerinnen und Entwickler bedeutet das: Aufwändige Integration, uneinheitliche Formate und wenig verständliche Dokumentationen erschweren die Nutzung. Im Schnitt zählt ein Portal weniger als 100 Zugriffe pro Monat, manche Datensätze werden so gut wie nie genutzt. Seit 2010 wurden über 250 Millionen Euro in solche Infrastrukturen investiert, dennoch finden weniger als fünf Prozent der bereitgestellten Daten produktiv Verwendung.

‍

Die Folge: Es entstehen teure Insellösungen, unnötige Doppelarbeit und Frust bei allen Beteiligten. Zudem wächst – insbesondere für Analyse-, Hosting- oder Aufbereitungsdienste – die Abhängigkeit von globalen Cloud-Anbietern. Das wiederum widerspricht dem Ziel, Europas digitale Souveränität zu stärken.

‍

Im weiteren Verlauf erläutert dieser Artikel, wie moderne Technologien wie Künstliche Intelligenz (KI) und das Model Context Protocol (MCP) helfen können, diese Blockaden zu überwinden und das Zielbild Open Knowledge in greifbare Nähe zu rücken.

‍

Open Data aus der Industrie: Data Spaces

‍

Während Open-Data-Portale sich primär an die Allgemeinheit richten, entstanden in der Industrie – vor allem seit 2015 mit der Initiative International Data Spaces (IDS) des Fraunhofer-Instituts – sogenannte Data Spaces. Ihr Ziel ist es, einen vertrauenswürdigen, dezentralen Datenmarkt zu ermöglichen, in dem Unternehmen sensible Informationen austauschen können, ohne die Hoheit über diese Daten zu verlieren. Projekte wie Gaia-X* oder dessen branchenspezifische Ausprägungen (Catena-X für die Automobilindustrie, Manufacturing-X für die Fertigung, Agrar-Data-Space usw.) bauen auf diesem Konzept auf.

‍

Zentrale Merkmale eines Data Space:

‍

• Souveränität: Jede Partei behält vollständige Kontrolle über Zugriffsrechte, Nutzungszwecke und Verarbeitungsregeln (sog. Data Usage Policies).
• Föderation statt Zentralspeicher: Daten verbleiben physisch beim Ursprungsunternehmen; ausgetauscht werden nur definierte Ausschnitte über standardisierte Connectoren.
• Semantische Interoperabilität: Gemeinsame Ontologien, etwa die Asset Administration Shell (AAS) als Digital-Twin-Hülle, sorgen dafür, dass Daten maschinen-verständlich beschrieben werden.
• Vertrauensanker: Identitäts- und Zertifizierungsdienste prüfen Teilnehmer, sodass auch geschäftskritische oder vertrauliche Daten sicher geteilt werden können.

‍

Dadurch können entlang der gesamten Wertschöpfungskette – von der Rohmaterialbeschaffung bis zum Recycling – Digitale Zwillinge aufgebaut werden, die Echtzeitinformationen über den Zustand, die Nutzung und den CO₂-Fußabdruck eines Produkts liefern. Anbieter von Maschinen, Logistik-Dienstleistern, Zulieferer sowie Betreiber erhalten so ein gemeinsames, jedoch fein granuliertes Lagebild, ohne ihre proprietären Datenbanken offenlegen zu müssen.

‍

Data Spaces ergänzen somit das öffentliche Open-Data-Ökosystem um hochaufgelöste, domänenspezifische Wissensschätze. Wenn beide Welten miteinander verbunden und für KI-Systeme wie Large Language Models leicht zugänglich gemacht werden, entsteht ein gutes Fundament für wirklich datengetriebene Innovationen – von präventiver Wartung über resiliente Lieferketten bis hin zu nachhaltigen Produktkreisläufen.

‍

Digitale Souveränität: Mehr als Serverstandorte

‍

Digitale Souveränität bedeutet Kontrolle über Daten, Infrastruktur und Wertschöpfung. Drei Missverständnisse stehen echter Souveränität im Weg:

‍

1. Infra-Fixierung – Server in Frankfurt ≠ Souveränität, wenn der Algorithmus aus Kalifornien stammt.
2. Portal-Zentralismus – Ein Portal für alles scheitert an föderaler Realität und Datenhoheit.
3. Download-Kultur – Offene CSV-Dateien sind kein nutzerzentrierter Service.

‍

Nur wenn Daten kontextualisiert, zugänglich und verarbeitbar sind, entsteht Wert. Wäre es nicht einfacher, die Open-Data-Portale in Data Spaces zu überführen?

‍

Data-Space-Architekturen – ob Gaia-X, Catena-X, Manufacturing-X oder die Querschnittsreferenz IDS – versprechen den heiligen Gral der Datensouveränität. Technisch liefern sie:

‍

• föderierte Connectoren, die feingranulare Nutzungsregeln erzwingen,
• Identitätsdienste, die Partner authentifizieren und zertifizieren,
• Policy-Sprachen, mit denen sich „Nutzen ja, weitergeben nein“ maschinenlesbar ausdrücken lässt,
• domänen spezifische Semantik-Modelle (z.B. Asset Administration Shell), die eine eindeutige Interpretation ermöglichen.

‍

Damit ist die Frage "Wer darf welche Daten unter welchen Bedingungen sehen?" inzwischen gut beantwortet. Offen bleibt jedoch die viel wichtigere Frage: "Und wozu?"

‍

• Nutzenlücke: In vielen Pilotvorhaben endet der Mehrwert beim "Bereitstellen können". Daten wandern zwar souverän von Connector A zu Connector B, doch kaum jemand bringt sie in produktive Anwendungen wie vorausschauende Wartung oder CO₂-Bilanzierung ein. Das Ergebnis ist ein regelrechter "Empty-Shelves-Effekt": aufwendig sortierte Regale, aber kaum verkaufsfähige Produkte.
• Semantische Fragmentierung: Obwohl Standards existieren, modelliert jede Branche – oft jedes Konsortium – zusätzliche Klassen und Properties. Ein vermeintlich einfacher Begriff wie „Batch“ kann in Chemie, Lebensmittelproduktion oder Pharma Unterschiedliches bedeuten. Integration kostet somit weiterhin manuelle Mapping-Aufwände.
• Fehlende "Last-Mile-Services": Data Spaces spezifizieren Transport und Governance, nicht aber Suchbarkeit, Visualisierung oder Entscheidungsunterstützung. Ohne diese Services bleibt der Datenstrom abstrakt – vergleichbar mit Autobahnen ohne Ausfahrten.

‍

Kurzum: Data Spaces legen eine sichere Pipeline, doch das Wasser muss erst noch zu Trinkwasser veredelt werden. Wenn KI-basierte Dienste wie LLMs sowie leichtgewichtige Protokolle à la MCP die Daten automatisch auffindbar, semantisch harmonisiert und in natürliche Sprache übersetzbar machen, schließt sich die "Souveränitäts-Wertschöpfungs-Lücke". Dann entsteht aus souverän geteilten Rohdaten tatsächlich nutzbares Wissen – von der Lieferketten-Resilienz über den Digitalen Zwilling bis zur Kreislaufwirtschaft.

‍

Von Open Data und Data Spaces zu einer Federated Knowledge Architecture

‍

In diesem Abschnitt wird ein konkreter Anwendungsfall beschrieben, der zeigt, wie durch die Kombination von Open Data und Data Spaces mithilfe von KI und MCP ein souveränes Architektur-Muster – die Federated Knowledge Architecture (FKA; dt. "Föderierte Wissensarchitektur") – entstehen kann, das echten Mehrwert schafft. Am Beispiel des geplanten Baus einer Fertigungshalle wird illustriert, wie dieses Architektur-Muster die Brücke zwischen offenen und domänenspezifischen Datenräumen schlägt und so innovative Wissenslandschaften ermöglicht.

‍

Federated Knowledge Architecture und System

‍

Federated Knowledge Architecture (FKA) bezeichnet ein Architekturmuster, in dem verteilte Wissens- und Datendienste über MCP föderiert werden. Es verbindet Open‑Data‑Quellen und domänenspezifische Data Spaces zu einer souveränen Wissensschicht für KI‑gestützte Auswertung – mit klarer Governance und ohne zentrale Datenhaltung.

‍

Das Federated Knowledge System (FKS) ist die konkrete Implementierung der FKA in einer Organisation oder einem Ökosystem – einschließlich MCP‑Servern, LLM‑Orchestrierung und Domänenadaptern.

‍

Komplexität des Bauprozesses – heute

‍

Der Bau einer Fertigungshalle ist eine komplexe Herausforderung, bei der zahlreiche Datenquellen abzurufen und zu berücksichtigen sind. Dabei geht es etwa um Umweltinformationen aus öffentlichen Open-Data-Töpfen wie Bodenbeschaffenheit, Trinkwasser- und Hochwasserschutz oder wissenschaftlich fundierte ökologische Aspekte für nachhaltiges Bauen, um den Einfluss auf die Umwelt zu minimieren. Gleichzeitig müssen branchenspezifische Data Spaces erschlossen werden, um Materialien mit geringstem CO₂-Fußabdruck auszuwählen, etwa für Baustoffe oder elektrische Installationen – eine Optimierung, die auch über die gesamte Lebensdauer der Fertigungshalle berechnet werden sollte.

‍

Aktuell bedeutet dies, verschiedenste Behörden und Experten aufzusuchen, Anträge manuell auszufüllen und aufwändige Abstimmungsschleifen in Kauf zu nehmen. Jeder Schritt ist zeitintensiv und fehleranfällig.

‍

MCP und KI – ein neuer Ansatz für Bauprojekte

‍

Hier setzt die Vision einer Federated Knowledge Architecture an: Mit dem Model Context Protocol (MCP) als föderiertem Datenübersetzer und lokalen Large Language Models (LLMs) entsteht ein Architektur-Muster, das diese Komplexität reduziert und den gesamten Datenzugang in einer einzigen, intelligenten Wissensschicht vereint.

‍

Wie eine solche Architektur funktioniert:

‍

1. Zugriff auf Open Data: Die Architektur ermöglicht automatisierten Zugriff auf öffentliche Datensätze – etwa auf Umweltkriterien oder wasserrechtliche Schutzgebiete. Mit Hilfe von MCP werden die verschiedenen Datentöpfe für KI-Systeme zugänglich gemacht.
2. Integration von Data Spaces: Über standardisierte Schnittstellen werden branchenspezifische Daten zu Baustoffen, CO₂-Bilanz und Materialkreislaufwirtschaft eingebunden.
3. KI-basierte Kontextualisierung: Ein leichtgewichtiges, lokal gehostetes LLM (z. B. Mistral oder LLaMA) aggregiert die Daten zu einer umfassenden Empfehlung. Sei es, um die optimalen Baustoffe zu bestimmen, Genehmigungen vorzubereiten oder ökologische Nachweise zu erstellen.
4. Automatisierte Erstellung von Dokumenten: Notwendige Unterlagen wie Bauanträge, Umweltverträglichkeitsprüfungen oder Fördermittelanträge werden direkt aus den Daten generiert.

‍

Das Ergebnis: Anstatt mühsam einzelne Behörden zu kontaktieren, Eingaben von Experten abzuwarten oder bürokratische Silos zu durchbrechen, kann ein Projektleiter mit einer einfachen Abfrage – beispielsweise "Wie plane ich eine ökologisch optimale Fertigungshalle im Trinkwasserschutzgebiet?" – relevante Bauvorschriften, Umweltanalysen und Arbeitsunterlagen schnell erhalten. Diese Informationen können während des gesamten Bauvorhabens immer wieder abgefragt und mit dem aktuellen Baufortschritt abgeglichen werden. Im ersten Schritt wird ein solches Architekturmuster noch kein Bauvorhaben vollumfänglich planen können, jedoch kann es enorm unterstützen, um auf plötzlich auftretende Änderungen schnell reagieren zu können.

‍

Technisch basiert diese Lösung auf lokal gehosteten LLMs, die über MCP-Server mit Echtzeitdaten aus den jeweiligen offenen Datenquellen und Data Spaces angereichert werden. Die Integration erfolgt dabei ohne Migration vorhandener Legacy-Systeme, was eine einfache Umsetzung ermöglicht.

‍

Datengetriebenes Bauen – ein Business Enabler für die Industrie

‍

Ein solches Architektur-Muster transformiert den Bauprozess fundamental:

‍

• Zeitersparnis: Entscheidungen, die sonst Wochen benötigen, können um ein Vielfaches schneller validiert werden.
• Nachhaltigkeit: CO₂-Fußabdruck und Ressourceneffizienz werden transparent in die Planung eingebaut.
• Kostensenkung: Durch Automatisierung und die Vermeidung von Doppelarbeit entstehen Effizienzgewinne, die vor allem kleinen und mittleren Unternehmen zugutekommen.
• Wettbewerbsvorteil: Schnellere, datengetriebene Entscheidungen steigern die Innovationsfähigkeit von Unternehmen in einem hart umkämpften Markt.

‍

So beschreibt der Anwendungsfall nicht nur einen technologischen Fortschritt, sondern zeigt auch den Weg hin zu einer modernen, KI-unterstützten Infrastruktur, die sowohl Open Data als auch Data Spaces nutzt, um den Übergang zu echter Open Knowledge Realität werden zu lassen.

‍

Aufbau einer Federated Knowledge Architecture

‍

Wie könnte eine solche Federated Knowledge Architecture konkret aussehen? Die folgende Grafik beschreibt exemplarisch, wie ein solches Architektur-Muster umgesetzt werden kann und wie der Ablauf einer Wissensanfrage abläuft. Um Übersichtlichkeit zu gewährleisten, werden nicht alle Datentöpfe aus dem beschriebenen Beispiel dargestellt. Die darin abgebildeten MCP Server können sowohl im eigenen System der Federated Knowledge Architecture bereitgestellt werden als auch in einem fremden System, zum Beispiel von einem Open Data Portal Betreiber.

‍

‍

Use Cases:

‍

• Ein "project manager" für ein Bauvorhaben stellt eine Anfrage für den Bau eines bestimmten Gebäudetyps und gibt weitere Rahmenbedingungen (Ort, Nutzungsdauer, Produktionsvorhaben, etc.) bekannt. Die Anfrage kann auch aus einem System heraus formuliert werden, das Bauvorhaben verwaltet.
• Ein Federated Knowledge System mit implementierter nimmt die Anfrage entgegen. Dann macht es diese Schritte: 1. Erstellung einer Liste von MCP Features, welche von den verfügbaren MCP Servern bereitgestellt wird. 2. Erstellung eines Prompts mit der Anfrage und allen verfügbaren MCP Features. Der Prompt enthält ebenfalls den Hinweis, dass bei zusätzlich benötigten Informationen die jeweiligen MCP Features auszuführen sind. 3. Schickt den Prompt an das LLM und wartet auf Rückmeldung.
• Das LLM interpretiert den Prompt und entscheidet selbstständig, dass es noch zusätzliche Informationen benötigt. Um an die fehlenden Informationen zu gelangen, meldet es dem Client, dass dieser ein bestimmtes MCP Feature aus dem Prompt aufrufen soll und die erhaltenen Daten wieder an das LLM zurückgeben soll. Sind alle benötigten Informationen vorhanden, antwortet das LLM mit einer finalen Antwort.
• Erhält der LLM-Client die Rückmeldung, dass das LLM die Ausführung eines bestimmten MCP Features benötigt. Der LLM-Client teilt dem MCP Client mit, dass dieser das entsprechende Feature auf dem MCP Server aufrufen soll und gibt das Ergebnis zurück an das LLM.
• Die verfügbaren MCP Server implementieren die jeweiligen MCP Features. Dabei greifen sie auf entsprechende Datentöpfe zu. Dabei kann der MCP Server direkt im System der Federated Knowledge Architecture betrieben werden, oder auch von dem Betreiber einer Daten-Architektur bereitgestellt werden. Der MCP Server selbst kann beliebig komplex sein. Dieser kann einfach nur API-Anfragen durchreichen, oder selbst komplexe Aufgaben erledigen.
• Das Federated Knowledge System nimmt die Antwort des LLMs und gibt diese an den project manager zurück. Die Antwort enthält somit das Wissen aller zur Verfügung stehenden Daten.

‍

Die ersten Schritte zur Federated Knowledge Architecture

‍

Das beschriebene Beispiel zeigt, wie die verschiedenen Systeme zusammenarbeiten. Je mehr MCP Server zur Verfügung stehen, desto umfangreicher werden die Antworten. Das beginnt bei der Zusammenfassung und der Empfehlung von Maßnahmen bis zur Befüllung von Anträgen und sogar die Steuerung von bestimmten Anlagen und Geräten ist möglich. Das Potenzial eines solchen Architekturmusters ist immens, um aus bestehenden Daten neue Innovationen zu kreieren. Doch wie lässt sich so ein System realisieren?

‍

Bevor eine Federated Knowledge Architecture umgesetzt werden kann, muss zuerst eine grundlegende Architektur festgelegt werden, wie sich der MCP Server und das LLM im Gesamtsystem positionieren.

‍

Diese Variante empfiehlt sich vor allem in der Anfangsphase. „Chat-Clients” erlauben einen sehr einfachen Einstieg in den Umgang mit LLMs. Zudem lassen sich so schnell MCP Server und die dazu passenden Prompts für fachliche Use-Cases entwickeln. Bei Bedarf kann ein eigener MCP Client als Plugin in einen Chat-Client integriert werden.

‍

Je weiter sich der POC-Use-Case entwickelt und je mehr Fachlichkeit umgesetzt wird, desto mehr drängt sich Variante 2 auf. Für komplexere Themen werden nach und nach mehr Informationen vom Nutzer abgefragt, welche sich strukturiert wesentlich einfacher erfassen lassen, als in einer Freitexteingabe. Zudem ist so eine Federated Knowledge Architecture auf bestimmte fachliche Kontexte ausgerichtet. So muss sich eine Architektur, die sich ums Bauwesen kümmert, kein Wissen zu speziellen Tieren zur Verfügung stellen, obwohl sie auf Datentöpfe zugreift, die sich gleichzeitig mit Themen aus der Zoologie in Sachen Tier- und Umweltschutz überschneiden.

‍

Der Einstieg in MCP ist im Grunde sehr einfach: Datensilos gibt es bereits genügend. Meist sind diese auch bereits mit einer API versehen. Auch wenn es nur eine Datenbank ist, kann diese problemlos an einen MCP Server angeschlossen werden. Die MCP Server Community entwickelt am laufenden Band fertige Integrationen, um zum Beispiel APIs, die per OpenAPI beschrieben sind, automatisch in MCP Features umzusetzen. Auch gibt es für viele Datenbanken bereits fertige Adapter. Das Gute an dem MCP Server: dieser muss im ersten Schritt selber gar nicht so viel machen. Er vermittelt lediglich zwischen dem LLM und dem Datensilo. Die Logik, die die Daten nimmt und verarbeitet, steht im Prompt selbst und wird vom LLM ausgeführt. Komplexere MCP Features werden sich mit der Zeit entwickeln, je mehr Use-Cases umgesetzt werden.

‍

Die Frage nach dem richtigen LLM ist relativ komplex. Um das Thema nicht unnötig aufzublähen, hier ein paar Grundgedanken, die dabei zu beachten sind, die neben dem allgemeinen Leistungsspektrum eines LLM berücksichtigt werden sollten.

‍

• Lokal oder As a Service: Lokale LLMs machen einen sehr unabhängig und maximal souverän, doch ist der Betrieb eines lokalen LLMs nicht zu unterschätzen. Hierfür ist meist leistungsstarke Hardware nötig. Oft ist eine „As a Service” LLM für größere POC schneller organisiert und auch günstiger in der Anfangsphase.
• EU oder nicht EU: Wenn es eine LLM als Service sein soll, muss entschieden werden, ob es sich um eine EU-konforme LLM (z.B. Mistral) handeln soll. Hier ist klar, dass amerikanische Modelle sehr ausgereift sind, doch ist hier unklar, wie mit den übertragenen Daten umgegangen wird. Für Use-Cases, in denen vor allem Text kontextualisiert werden soll, reichen auch kleinere Modelle, die von europäischen Anbietern stammen.

‍

Hinweis zu gpt-oss (Open-Weight-LLMs): Mit der Vorstellung von gpt-oss-120b und gpt-oss-20b, die unter Apache-2.0-Open-Weights veröffentlicht wurden, verschiebt sich die Balance im Architektur-Muster deutlich: Lokaler Betrieb wird günstiger, souveräner und leistungsfähiger. FKA kann so modell-agnostisch bleiben – ein Wechsel zu gpt-oss erfolgt einfach über eine andere Modellreferenz im MCP-Layer, ohne Architekturänderungen. Weiterhin bleibt Governance durch Prompt-Logging, Evaluierungen und Sicherheitstrainings essenziell.

‍

Grundsätzlich sollte eine LLM so integriert werden, dass diese ausgetauscht werden kann. Dafür eignen sich gängige Architekturmuster. Die Welt der LLMs dreht sich schnell, somit ist es sehr wahrscheinlich, dass die Modelle nach und nach ausgetauscht werden müssen. Dies kann sowohl aus Gründen der Kostenoptimierung und der Steigerung der digitalen Souveränität kommen, als auch regulatorische Vorgaben, die einen zwingen zu wechseln.

‍

Nachdem die technischen Rahmenbedingungen gesetzt sind, muss nur noch losgelegt werden. Da sich durch Initiativen wie Big Data, Open Data und Data Spaces in Unternehmen und Behörden zahlreiche Datensilos gebildet haben, findet sich bestimmt ein passendes Silo, mit dem angefangen werden kann.